Learning by Shipping

Creating a product, whether totally new or an update, means deciding what’s in and what’s out.  The main execution constraint you have is the time you are willing to spend developing your product (or the number of developers, roughly the same thing).  In your planning you need to decide the right amount of work to do to create, or justify, the product—rightsizing your product plan.  Executing a rightsized plan without compromising your vision is a core product development skill.

What is rightsizing?

While most all product development debates take place at a fairly granular level—having a specific feature, architecting an investment, choosing how to communicate the work—there are some broad topics that can have a profound impact on how the product evolves.  The most critical first step of a project is to decide the “scope”.  Deciding the scope of a project is an active conversation across all the stakeholders involved.

For software and service projects (note, project=product=service) the scope determines a whole host of choices, and even how you articulate the scope can open up or foreclose options.  You sort of need to start by checking in with the realities of your foundation:

Entirely new product.  An entirely new product is the opportunity to scope a product to a minimal set of features or needs.  In other words you can literally pick the smallest set of features/investments to express your scenario or goals.  It has become common to refer to this as a minimum viable product or MVP.  Another aspect of “new” is whether the project is new to your company/organization or new to the industry as a whole.  There’s a tendency to view scoping differently if something is entirely new to the world versus new to your organization.  An MVP can take on one meaning for a startup where there are no expectations for “minimal”.  For an existing company, this becomes increasingly challenging—things like globalization, accessibility, security, integration with existing account infrastructure, and more can set a significantly higher bar for “minimal”.

Evolving an existing product. Most all software is about evolving an existing product.  In scoping the work to improve an existing product the main dimensions that determine the scope will be compatibility with the current product—in user experience (keystroke, flow), data (file formats, previously saved work or settings), features (what a product does), or platform (APIs, add-ins).  In scoping a product plan for an existing product, deciding up front to maintain 100% of everything itself has a cost, which to the outside world or management, might be counter-intuitive.  Regression testing, design constraints, and even what you choose to do differently with existing features determine the scope of the new work for the release.  Sometimes a product can be new for the company even if it evolves an existing product, but these same constraints might apply from a competitive perspective.

Disrupting an existing product.  Any project can evolve for some period of time and eventually requires a significant overhaul—scenarios change, scale limits reached, user experience ages, and so on.  A project that begins knowing you will disrupt an existing product poses a different set of scoping challenges.  First and foremost you need to be clear on what part of the project you are disrupting.  For example, are you considering a full re-implementation of an existing product or are you re-architecting a portion of an existing product (again, say the UI, API, or features)?  Sometimes a product can be new to your organization but disrupt a competitive product, which brings with it a potentially different view of constraints.

Side-by-side product. One type of project scoping is to decide up front that your project will coexist with a product that solves a similar problem from your customers/company/organization.  This approach is quite typical for internal IT systems where a new system is brought up and run in parallel with the old system during a switchover period.  For a consumer product, side-by-side can be a shorthand for “keep doing it the way you’re doing it but try out our system” and that can apply to a specific set of customers you are targeting early in development.

Each of these is more granular and real-world in an attempt to cover more of the software projects so many of us work on.  Typically we look at projects as “new product” or “update” but tends to over-simplify the project’s scope.

Many projects get off to a rocky start if the team is not clear on this one question of scope.  Scoping a product is an engineering choice, not simply a way to position the product as it is introduced.  For example, you might develop the product as an evolution of a current product but fail to get some of the baseline work done.  Attempting to position the product as “totally new” or “just run it side by side” will probably backfire as many of the choices in the code do not reflect that notion–the seams will be readily apparent to customers (and reviewers). As with many challenges in product development, one can look back at the history of projects, both successful and not, and see some patterns to common challenges.

Pitfalls in scoping

Deciding and agreeing up front to the scope of your product is a critical first step.  It is also easy to see how contentious this can be and can often generate the visceral and stereotypical reactions from different parts of a collective team.

If you develop an enterprise product and propose something that breaks compatibility you can expect the scoping efforts to be met with an immediate “requirement” that compatibility be added back to the plan from your enterprise sales force, for example.

A consumer product in a space such as note taking or writing, as an example, can certainly be immediately overloaded with the basics of text processing and image handling.  Or one can expect reviewers to immediately compare it to the current most popular and mature product.  We’re all familiar with the first release of products that received critical reviews for missing some “must have core features” (like copy/paste) even though they had a broadly disruptive first release.

The needs for a product to be global, accessible, or to plug into existing authentication mechanisms are examples that take a great deal of up front work to consider and clarify with the team (and management).

In fact the first pitfall of most scoping efforts might be the idea that disagreements up front, or just different points of view that have been “shelved”, will be easily resolved later on.  One coping mechanism is for folks to think that the brilliance of the product’s innovation will be apparent to all parties and thus all the things “out of scope” will go from a disagreement to shared understanding once people see the product.  My experience is that this isn’t always how it works out :-)

The most difficult challenge when you’re scoping the project is that you actually considered all of these “obvious” things, yet as people see the product (or plans) for the first time these come across to them like obvious misses or oversights.  You probably know that you could add features that exist in the marketplace, that you’re breaking compatibility, that you’re going to need to run side-by-side, that you’re not ready for complex character sets, and so on.  Yet as the product is revealed to peers, management, reviewers, or even as the team sees the whole thing coming together there’s always a chance of a bit of panic will set in.  If you’ve gone through an effort to plan the scope, then none of this will be news and you will have also prepared yourself to continue forward progress and the discussion for how and why choices were made.

Even with that preparation, there are a few common pitfalls to project rightsizing that one needs to consider as a project goes from planning through execution.  These pitfalls can surface as the product comes together and the first customers see it or these can be the reason the product isn’t getting to a stage where others can see it:

• Backing into a different scope.  The most critical failure of any project is to think you can revisit the scope of the project in the middle, and still stay on time.  If you decide to break compatibility with the existing product and build out new features assuming this approach then you’re faced with rearchitecting the new features, cutting them, or some decidedly tricky middle ground.  Taking a step back, what you’re really doing is revisiting the very approach of the whole product.  While this is possible, it is not possible to do so on the schedule and with the resources you have.
• Too much.  Most all of us have scoped a project to do more than we can get done in the time and with the resources we have.  A robust product plan provides a great deal of flexibility to solve this if you were clear on the scope—in other words a feature list that is too long is easy to trim.  This is decidedly different than trying to change scope (change from disrupting the product to evolving the product for example).  If all you have is too many features, but the intent of the release is consistent with that long list—I promise there are features to cut.
• Too little.  In the current climate where MVP is a perfectly good way to develop innovative new products, you can still scope the product to do too little.  In the new product space, this could be a sign that you have not yet zeroed in on the innovation or value-add of your product.  Similarly, any project that involves a data center deployment (or resources) and a commitment from partners can also be scoped such that the collective investment is more than the collective return on that investment.  In the evolution of existing products, such a release might be characterized as simply too conservative.  It could also lack focus and just be a little bit of stuff everywhere.
• Wrong stuff.  Often overlooked as a potential pitfall of product scoping is a choice to solve the wrong problems.  In other words the plan might be solid and achievable, but the up-front efforts scoped the project on the wrong work.   This is simply picking wrong.  The trap you can fall into is how you cope with this—by simply adding more work or on-the-fly rescoping the product to do more or change scopes.  Wrong stuff is a common pitfall for evolving existing products—it is when the scoping efforts lacked a coherent view of priorities.
• Local or global optimization.  Scoping a product is essentially an optimization function.  For an existing product that is evolving, there is a deliberate choice to pick an area and re-optimize it for a new generation.  For a new product, the MVP is a way of choosing a place in the value chain to optimize.  This scoping can be “off” and then the question is really whether the adapting that goes on during the project is optimizing the right plan or the wrong plan.  This optimization challenge is essentially a downstream reaction to having picked the wrong stuff.  You can A/B test or “re-position” the product, but that won’t help if you’re stuck on a part of the value curve that just isn’t all that valuable.  Is your optimizing truly about an optimal product or are caught in a trough optimizing something local that is not enough to change the product landscape?

Of course projects go wrong in so many ways, some major and some minor.  In fact, part of product development is just dealing with the inevitable problems.  Nothing goes smoothly.  And just like Apollo 13, when that first glitch happens you can think to yourself “gentlemen, looks like we had our glitch” or you can stay alert knowing that more are on the way.  That’s the nature of complex product development.

Approach to rightsizing

Rightsizing your project up front is a way to build in both constraints and flexibility.

Rightsizing is clarifying up front the bounding box of the project.  If you’re clear about the mechanical and strategic constraints of a project then you’ve taken the first step to keep things on track and to make sure your commitment to your team, customers, and management to develop a product can be met.  One way to think of these constraints is as the key variables for project scoping—you rightsize a project by choosing values for these variables up front.

Mechanical constraints are the pillars of a project from a project management perspective.  You can think of these as the budget or the foundation, the starting point:

• People.  How many people are going to work on the project?  This is the simplest question and the easiest one to fix up front.  A good rule of thumb is that a project plan should be made based on the number of people you have from day one.  While many projects will add people over time, counting on them to do critical work (especially if the project is not one that lasts years) is almost certain to disappoint.  Plus most every project will have some changes in staffing due to natural people transitions, so the best case is to assume new people can fill in for departing folks.
• Time. The next easiest scoping variable is how long your project will last.  Whether it is weeks, months, or years you have to pick up front. Proponents of continuously shipping still need to pick how long from the time code is planned and written until that particular code is released to customers in some way—and of course that can’t be done in isolation if multiple groups have code to release.  As with people, you can add more time but you don’t get proportionally more work.  And as we all know, once the project starts just making things shorter usually fails to meet expectations :-)  Many stakeholders will have a point of view on how long the project should last, but this cannot be viewed in isolation relative to what you can get done.
• Code and tools.  For any project that is starting from an existing product, one should be deliberate about what code moves forward and what code will be replaced/re-architectected.  Starting from an existing product also determines a number of mechanical elements such as tools, languages, and cloud infrastructure.  For a new product, picking these up front is an important rightsizing effort and not the sort of choices you can revisit on the fly as often these impact not just the schedule but the expression of features (for example, native v. HTML5 app, or what infrastructure you connect to for authentication).  Choosing the code up front will bring in many stakeholders as it impacts the scope of the project relative to compatibility, for example.

While each of these mechanical attributes are relevant to the product strategy they don’t necessarily define the product strategy.  Commonly, products talk about release cadence as a strategy but in actuality that is an expression of the mechanical aspects of the project.  Strategic constraints are the walls of your project that build on the foundation of your mechanical constraints.  Your strategy is how you make choices about what to do or not do for the product.  There are a couple of key strategic constraints to address up front:

• Big bets.  Every project makes a very small, or even just one, big bet.  For an existing product this might be a bet on a new user interface or new business model.  For a new product this might be the key IP or brand new scenario.  The big bet is the rallying cry for everyone on the team—it is the part everyone is going to sacrifice to make work.
• Customer.  Every project needs to start off knowing who will be using the product.  Of course that sounds easy, but in a world of scoping a project it means that every potential customer cannot be served by a project to 100% of their needs or wants.  Knowing how you are delivering value to the relevant customers is a key rightsizing effort.  If you’re building on an existing product and breaking with the past or building a new product, then by definition some folks will not see the product as one that meets their needs.  It does not mean you will never meet their needs nor does it mean every customer like that will see things the same way.
• Long term.  When rightsizing a project you want to know where you are heading.  There are many ways to do this—some very heavy and some very lightweight.  The context of your business determines how much effort to put into this work.  If you know where you are heading over time, not just one release, then you can connect the dots from what is missing today to where you will be after one or more turns of the crank.  A long term discussion is not the same as long term planning.  Long term planning is a heavyweight way of making commitments you probably can’t deliver on—we all know how much changes in every aspect of the team, market, business, etc.  But long term discussion allows everyone to get comfortable that “thinking” is happening.  One way to think of this tool is to make sure the dialog is what the team is thinking about, not what the team is doing, so that the long term dialog does not morph into long term commitments.

The first step in building a product plan is to scope the product—rightsizing.  It is common to fall into extremes of this step—being extremely minimal or being too broad.  In practice, the context of your business contributes to determining what viable alternatives to rightsizing are.  There are tools you can use to actively rightsize the project rather than to let the size of the project just sort of happen.  Rightsizing the current project with a longer term view as to where you are heading allows projects to be scoped without compromising your vision.  As with any aspect of product development, being prepared and knowing that these challenges are in front of you is the best way to manage them.

–Steven

###