Posts Tagged ‘planning’
At the extremes of product development methodology, characterized by waterfall and agile approaches, are different views about planning. Many today would say that planning a product “up front” is nothing more than guessing that locks you into a guess that will be wrong. At the other end, the conventional wisdom is that you should get something to the market soon for testing as a best guess and then iterate and learn to further develop a product. Since no team really practices a method precisely, let’s look at how to get the best out of the planning aspects of your own product development process.
Developing a product, new or an update, always faces the same challenge at the start. Using software as an example, folks want to get coding as soon as possible since not coding is clearly wasting time, but the team (and management) want to know that the code will yield the right product (useful, cool, innovative, profitable, whatever). There are usually those on the team that claim instinct tells them what to go build. There are those that are certain they can work out an answer to the right product with enough up front ideation.
To compound these broad challenges, different disciplines have different perspectives. It is likely testers will want to spend more time up front on building a baseline and foundation for the work, but a baseline relative to what? Ops needs to know answers to questions in order to scale and provide the required infrastructure, but those answers require a lot of information you probably don’t know. Designers usually want time to iterate in lower fidelity media in order to hone in on the design language and overall approach. Business folks want to know that their key problems (onboarding, churn, referrals, etc.) will be addressed.
All of these lead to the natural tension between a desire to get started and a desire to pause and make sure the start heads in the right direction.
Waterfall (using this as a positive description) methods argue that an effort should begin with work to identify the problem being solved, available technologies, and proposals for how to go forward. The basic notion is that you should spend the energy considering a wide range of alternatives before you just start down a path that might be fruitless. These days you will be hard-pressed to find proponents of waterfall approaches because of the downsides often associated with waterfall execution.
The downsides of this approach, as critics claim, is that you waste a lot of time building up robust plans that are “going to be wrong (or outdated) anyway”. This criticism essentially states the reality that most plans are still guesses. This is particularly true in a fast-changing, multi-player marketplace where you can wake up one morning to a competitive product or dramatically new approach to solving the problem you identified many moons ago. The ultimate downside of the waterfall approach is that it is viewed as stubborn—so stubborn that even in the face of awareness about a changing market, the team has no choice but to move forward. Proponents will offer tools to mitigate any of these risks and say none of the risks are intrinsic to the methods.
Agile development methods respond to these criticisms by creating an approach where the primary focus is to get enough product work done so you can learn from real customers and then iterate. At the extreme, efforts should actively strip away all non-essential elements of the product development process and focus on the essence of the idea. Agile methods focus on constant iteration, learning, and responding to usage of the product (or lack thereof). Teams focused on iteration work in a tight loop to quickly adapt to the changing landscape and competitive dynamics, in addition to learning.
The downsides of agile methods are actually trickier to pin down right now. These days being critical of agile methods labels one as somewhat of a Luddite in the world of product development. That said, there are understood challenges with agile methods. The pressure to release can often result in a quality bar that is less than customers (or your own testers) would appreciate. A focus on learning might cause you to learn that your service does not scale or scales in a cost-ineffective manner. A large project (people, code, partnerships) is challenging enough to keep coherent and multiple efforts executing in different iterative loops poses a significant architectural and communication challenge. Proponents will offer tools to mitigate any of these risks and say none of the risks are intrinsic to the methods.
It is no surprise that proponents of any method can point to successes, while critics can point to failures of methods as well. In reality, the causal relationship between a project success and the method used is weak at best. Even with examples of success, we need to keep in mind that product development projects are not traditional repeated processes and as such the ability to draw scientific conclusions from them is limited. This should be apparent from the fact that successful products come from both methods, and equally true is that products can be failures from both methods.
It is not unusual for failures in waterfall-styled projects to be ascribed to the methods, but not so with successes. Whereas failures in agile projects usually ascribed to external factors, not the methods. In today’s climate, it is not unusual for agile to be viewed as a causal factor for a successful product.
That’s really why starting the project by declaring the methodology runs the risk of missing the big picture. It runs the risk of spending finite and scarce time on abstract or “meta” concepts and not the work at hand. The best thing is to avoid going down that path in the first place and focus on getting clarity on what work will get done and when that will happen (and why!).
The truth is that starting a product is always a guess. Whether you plan every detail or just start coding, beginning a new product is a leap of faith based on intuition. To those of us that build or have built new products, this leap is the most interesting, terrifying, and rewarding part of product development. It does take a special confidence to make that leap. Planning every last detail can give you a false sense of security. Coding out of the gate can give you a false sense of progress. Guessing is guessing, whether you have 1000 pages of specs and high fidelity model or a whiteboard with a sketch and a functional prototype.
These challenges—choosing between methods and the known challenges of any methods—are real. In product development we are faced with these every time we start a new project. If you have a clear starting point, clear points in time to check on your progress, and a plan so you know what you’re working against then you’ve defined a methodology that works for you.
Where to start?
In a previous post we talked about focusing on the work and not worrying about the label of the methodology. A concrete way to realize this is to take a step back and see how to combine the elements of agile and waterfall in the right amount for your project.
An approach that scales from new projects to next iterations, and small project to big, is to plan to iterate your plans. While this sounds like an obvious cop-out to pick the best of both extremes, it is what reality tends to look like in practice. If you start out knowing you are going to commit time to up front planning, but recognize you will take points in time during development to adjust and learn, then you can mitigate the challenges of both methods.
Of course agile proponents say there are always some plans. And waterfall proponents always say there is room to adjust. Let’s just say those labels and attributes don’t matter and try to arrive at an approach of where to start.
Every project can start with a plan. Legendary products start with a sketch on the back of a placemat at a diner or an all-night coding session. The original plans for some pretty big projects were conceived and documented in pretty short, but articulate, memos or detailed sketches/prototypes. The spark for a plan can come from anywhere and different people have different ways of translating that spark into something more than one person can internalize and visualize.
While a tool like PowerPoint can communicate the gist of the plans, the details will be too open to interpretation. So write down the plan in long form—writing is thinking.
The simple act of writing down a product plan in a couple of dozen pages opens you up to have useful discussions with a broad set of people. If you’ve identified the problem being solved, competitive products/services, technology bets, and overall investments you have the basis of how to talk with marketing, design, development, testing, and product management. Everyone can look at the plan from their perspective and offer insights, advice. You can even package this up as a dialog or exercise with potential customers.
Combining this overview with a functional low-fidelity prototype is a way to visualize the plan for a broader audience. It is usually a good idea for the prototype to support the written description and to lead with the written description. You’ll want to minimize the time you spend on “don’t worry this UX (user experience) isn’t final” or responding to feature suggestions without the context of where you are heading.
This is all a plan needs to be. It is a guess. You can’t prove it is right. You can’t prove it is a good business, great product, or the right thing to do. You can criticize it. You can add more to it. You can find problems. That will be true of any plan (or frankly any product). But you now have a foundation to move forward. To build something that is a “target” that is shared by a group—a vision.
With this plan comes the first chance to iterate. What’s amazing about just writing this down is how much you’ll find you’re iterating on your own thinking. You can think of this somewhat as agile planning. This shouldn’t be new though – anyone who has “told a story” of a product or an idea knows that the story improves quite a bit as you tell it more. This is basically the same thing. Any good product plan is a story—the problem you are solving is the challenge to overcome, the competitors are the antagonists, the technology bets and investments are the plot devices.
Depending on the size of the team/project, the next steps are about the specifics of what to do when. The amount of up front work and the ordering of the tasks is really a choice the team needs to make. Being economical about what you do is of course a key part of ordering. Agile methods often say to do the least possible work to express the unique value of the product. Waterfall methods are about landing all the details early. Different projects will simply have different ideas of what to do at this point and your own intuition as to what makes a good investment of time, relative to quality and time to market, will dominate.
Iteration: Local or globally optimize?
Regardless of the specifics of your development schedule, you are going to iterate. You can choose to iterate after code is in the hands of customers (in a broad or limited way) or just self-hosting until a broader release. The key though is to iterate.
Iteration is as much of an art form as deciding how much of what investments to do up front. It is super easy to fall into a trap of iterating but not making forward progress. You can find yourself rewriting the same code, circling back to previously discarded alternatives, or just changing things but not making them better. As necessary as iteration is, simply iterating does not mean you and the project are moving forward.
The lack of iteration or iteration at only the most fine-grained levels is potentially a sign of a project that won’t learn as it goes. Consider a standard kitchen remodel, something that has been done millions of times. Architects draw up plans and pass them off to contractors. Then you run into existing conditions. You find you’re missing an electrical run or there’s a support wall where one wasn’t expected. It is time to iterate on the plans. You can hack through a solution with your contractor on site. Or you can take a step back and work with the architect to reconsider the design. Either can work depending on your constraints. When you consider the time value of choices, it becomes more interesting to think about taking a step back.
In the heat of the moment with the need to get in market or respond to significant challenges with early customers, a redesign or revisiting decisions seems risky. Maybe the data is poor. Maybe the fear of discovering the need for big changes concerns you. Perhaps you just want to keep moving forward. All too often when problems arise in a project the need to iterate quickly trumps taking a step back. In today’s environment it is often viewed as a positive to iterate and try something different. Activity is not always progress. Change is not always improvement.
Of course the data you use to determine what to try and how to value the feedback is important. It is just as easy to get led astray by the wrong measures of success/failure. Regardless of the quality of data, you’re going to reach a point where you are faced with the need to change something. The question is whether the changes are the right ones.
The point of a change will be to optimize your product. You’re going to have to pick the dimension for which you want to optimize—is it for immediate mitigation or longer term success. It is easy to see mitigating the immediate challenges with some changes. Longer term might feel like another guess. On other hand immediate changes have an obvious fragility relative to broader goals and there’s clearly an appeal to being thoughtful about what to change.
Having a sense of a plan helps you to weigh the alternatives. Are you dealing with a bug or minor design nit or is there a fundamental flaw in the value proposition? There’s no mistaking the reality that you might hit a major reset, especially on a brand new product. There’s also a reality that you will have to revisit a pretty broad set of small design choices—that is steps in a flow or portions of a design, rather than the entire flow or design language.
Defining a time up front when the product is in a state to evaluate all the feedback and make choices about how to optimize is an important part of the process. This checkpoint stage can be a first self-host, private beta, partner beta, public beta or anything in between. Any product today is going to have telemetry and an understanding of how it is used and what you are measuring. This helps you to inform both what is going on and even what you failed to measure correctly.
Armed with a set of potential problems to address—optimizations yet to be done—there’s a simple question to ask of the team, which is “do we need to change/fix this or not, and if we need to take a step back and re-evaluate?”
A way to look at what to change/fix or not is to think of changes relative to the longer term goal, to go beyond the immediate. There’s no doubt the feedback about something is real. The question is really whether the cost to change (hours, risk, churn) gets you closer to the broader goals of the plan or is more reflective of iterative activity.
A checkpoint discussion where members of the team are aware of all the changes going on and what is being prioritized is a way to level-set. Some teams might have bigger challenges or more changes and other teams might be making more local changes. Calibrating these across the team is akin to making sure the whole project is thinking and acting globally, not locally. The plan that was put in place serves as a reminder of what the team was hoping to accomplish. Accountability, aka decision making, can be clear because the roles and responsibilities are clear and communication has been clear. A discussion to inform doesn’t have to be an invitation for everyone else to join in revisiting the choices made by the team.
Is the new data driving you to revisit the plan completely (whether immensely detailed or not)? That could be. For a brand new business and/or a brand new product where the effort is to grow an entirely new customer base, you could be going in a wrong direction. For a product update, there’s always going to be pressure from existing customers to innovate in a more incremental manner versus taking the product in a new direction. The presence of a plan allows you to have an informed dialog as to what went wrong. When you make choices to change things you have a shared foundation upon which to agree about what went wrong.
Is the data driving you to tweak something? That certainly is the case with some changes. The presence of the plan allows you to decide how critical it is to make changes. Too often changes to the code are made because of the presence of feedback even if the change doesn’t really alter the overall outcome. When you choose to keep things a bit more stable it doesn’t have to be viewed as blindly sticking to a plan when it can just be prudent engineering of cost-benefit. The capability to change is not the same as the value of change. Something that might be 10% better might introduce a high risk of change management or might just be 100% different–ask if something really is twice as good (or 10x better) after the change.
There’s a simple view of optimization that one can use in having discussions about changes—whether at the feature level of the whole plan. The idea is to discuss whether the change is a global optimization or a local optimization. When resources are right and time to market critical, optimizing locally is wasteful. When the plan is generally right but has some holes you discover, then making sure you optimize globally leads to an agile view of planning. The following just sketches this conceptual view–believe it or not this can often be a useful visual aid in the discussions around whether a change is needed.
Whether you label the axes performance, suitability to task, conversation rate, success rate, or transactions per second is not really as important as taking a step back and asking the question about whether the change gets you close to where you need to be over time. It is far too easy to get caught optimizing your plan relative to the nearest peak, not the best peak.
Whenever you have more than a few folks working together, having a set of tools to help you make a consistent set of choices across the team is critical. The more there is a shared view of the goals and the way to make choices the easier this becomes—a plan is a way of encapsulating the broader goals and giving you a place to both measure relative success and to decide the target was wrong. The presence of a plan does not enforce rigidity any more than the use of agility guarantees you will iterate to success.
Product development is a lot of guesswork. Planning, checkpointing, and deliberate decision making are tools to help you make the most informed guesses you can make.
This Week’s Poll
This week kicks off a new feature of Learning by Shipping — Three Quick Questions. This is a snap poll to share aggregate (non-scientific) reactions to the topic of this post, which will be reported in the next post. Take the poll – Three Quick Questions. Cameron Turner, an expert in big data and measuring how products are used in the real world is helping with these polls. No identifying information is collected or maintained.
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.
One of the biggest challenges of building technology products is that to bring a technology product or service to market requires great engineers to do their best work without really knowing the answer as to whether the choices being made will yield success or failure. This seems obvious but is often the greatest source of tension in a product team and just about every juncture.
Note: When saying “engineer”, please take it to mean all of the specialized skills involved in building a product inclusive of development, testing, design, operations, and more, and when saying “sales” or “marketing” take that to mean all of the specialized skills involved in getting a product into the hands of customers and supporting it—there is a spectrum of skills and responsibilities, which is critically important. No matter how many or how few specializations, the seams between roles are always fuzzy and that is good.
Natural tension [sic]
Any non-engineer who has ever interacted with an engineer knows the challenge (or frustration) of being told something can or can’t happen, or that something is right or brain-dead, or worse the stupidest idea ever. Likewise, every engineer knows the frustration of dealing with a salesperson, marketer, or customer who insists on something being done a certain way but can’t offer any rational explanation. This is often referred to as a natural tension or instituted balance of power on a team.
But who wants an instituted tension? There’s enough stress in just doing what needs to be done from your own perspective without the need to institutionalize more with no hope of resolving it.
The challenge is not easily overcome. Sure you can have engineers visit customers or you can have sales folks sit in on an architecture review, but these are anecdotal and don’t really infuse the relative challenges and contexts each party faces. In fact there is no easy answer because the reality goes back to the training, culture, and even time horizons of the different members of a product team. Rather than assume a natural tension, rely on anecdotes, or attempt to converge the DNA of the team there might be a better approach.
If you think about a team as a set of folks each coming to work to make difficult choices each and every day (and night!) then the critical element for the team is a shared and detailed sense of the overall plan for a product. Historically software planning has not matured to the degree of planning for most other engineering endeavors (construction, transportation). For the most part this is viewed as a positive—it is the “soft” part of software that makes it fun, agile, and in tune with the moment. Likewise, in the world of blogs and social media, the ability to re-craft the message to customers about a product can change much more rapidly than the days of lead times and print advertising. Again this is also a positive.
But if each perspective on a team is maximizing their creativity and agility, it doesn’t take long for chaos to take over. And worse, if things get chaotic and don’t come together well then fingers start pointing. Throw in a bit of performance evaluation or an executive meeting and what was a small disagreement becomes a wedge or worse, “politics”, very quickly. It is often amazing how quickly the most well-intentioned folks working together can start to have that so-called natural tension turn into a genuine dysfunction.
A plan for what is being built can sound so heavy or burdensome. It can be. It doesn’t have to be. Another word for a plan is a “framework for making decisions”. It is easy to make a plan that says all the amazing things that will be done and all the amazing ways money will be made. That’s the easy part.
Another easy part is listing all the things that won’t be done–sort of so everyone is clear on the inverse of what is being built. This sounds weird. I remember the first time I learned of a technique of deliberately detailing the non-goals or cut features of a project. I found this a puzzling disclosure–and maybe it was a specific device in a limited set of teams. If you list the project goals, then isn’t anything else that can be talked about a non-goal? The same goes for detailing features or outreach plans by priority. A lot of times you see lists of features/goals with priorities but that leaves it unclear which ones will get done (all the musts and a few maybes, most of the musts, etc.) – it seems best to simply list the ones that you’re signed up to do since for the most part I don’t think any of us have worked on a project where there was a surplus of time or money!
The hard part about making a plan is establishing the context of why a product is being built and how it will be successful. This is the social science aspect that is tough on an engineer. You can’t prove something will be a success in the market since there are no equations that govern market behavior. Similarly, the role of the technologist is to draw a trajectory of technologies to a world that might be different from the here and now, the here and now where people are spending money today. This is the social science that is tough on the sales and marketing team members.
What’s in a plan
For a project of any size that goes beyond a handful of people or involves any complexity, detailing the how and why of a product, not just the what, is a critical first step. The reality is that every member of the team benefits from the context and motivation for the project. Armed with that information there is a basis upon which to make decisions—decisions about how to implement features, decisions over priorities of features, decisions about how the product will be positioned or sold, and so on. It is amazing how often you run into engineers that know precisely what “needs” to be done but there isn’t really a good story as to why, or conversely how often you can find the marketing folks knowing what story would sell well but don’t know how to create that story. The point of a plan is to build a bridge made up of the how and why, not the what.
Of course things change. Code is harder to write than you would like. Competitors fill a void. Customer views change. In fact any project is going to go through a phase of questioning parts and resetting details of the plan. The most counter-intuitive notion of a plan is that the presence of a plan means you have the tools to change the plan, together as a team. The absence of a plan is what creates the chaos, finger-pointing, and accountability dodging that we’re all familiar with. A plan does not imply rigidity, but like any tool a plan can be abused. There are people who think plans are chiseled into stones. There are also people who think a plan is just a starting point and that everything is dynamic. Product development is a dynamic system with plans provided the needed anchor points for the team as a whole, across disciplines.
Some things you might take into consideration when working to create a plan might include:
- Current product state. If you’re updating an existing product, then there should be a shared understanding of how the current product is being received in the market. What are the strengths and weaknesses technically and in terms of the business? Those responsible for selling and supporting the current product should lead the creation of this content.
- Business opportunities. Where are customers spending money? Where would they be willing to spend money? For competitive products, how are these products sold? In most teams there are people who deeply understand the revenue model and cost structure of a product and those folks should lead the creation of this part of the plan.
- Competition. Everyone should understand the competition. This is not the sort of thing that should be done casually, but everyone on the team should know the competition inside and out and use competitive products and services full time. A lot of damage gets done to plans when people casually try out a competitor and don’t make the mind shift required to understand why customers might be migrating to competitive products. And keep in mind that competition might be disruptive and offer a product with “less” functionality but with a different model for making money. Driving this part of the plan requires teamwork.
- Partnerships. Every technology product is made up of partnerships. Building a platform, an app, hardware or software requires partnerships with developers, hardware makers, component makers/supply chain, post-sales deployment / support (for enterprise products), and more. Even something as basic as a plug-in model or extensibility API needs to be thought through if you want it to be part of the decision framework for the team. Again, this part of the plan requires the team’s perspective.
- Industry trends. The social science of putting a plan together really kicks in when the team starts to consider what the technology trends look like. What’s the timeframe? What’s the likelihood of a trend panning out? What is the upside / downside to the project if a given trend pans out or not? These are important questions. But agreeing up front on the waves a product is riding and being detailed enough that everyone is clear is important. This is where the nuance of a plan really comes into play. Today every plan might say “mobile” but the question is much deeper than that when it comes to how to act—how does that relate to monetization, what platforms, and the relationship to the browser are all critical “trends” to articulate.
- Define success. What does success look like? As part of planning, sometimes a tool that is helpful is to pull together all the above and write the announcement blog post (aka press release). Is that credible? How would competitors respond? Engineers should consider defining success in terms of simultaneous users, transactions, or performance in addition to the features. Everyone works together to define success.
- Timeline. Every good project starts with a timeline. And most projects quickly revise that. The real challenge with any planning effort is to pick a timeline that you genuinely believe in up front as a team and then use the above efforts to make tradeoffs to stick to the timeline. If you’ve scoped the work to the timeline and set an achievable timeline then changing the plan to account for unknowns is how you keep everything real. Because developing a plan is iterative, the timeline is informed by the plan–you don’t take the plan then go decide what can get down (or how long it will take), like the old waterfall model.
When you look at this framework three things might jump out.
First, the plan is not a top line business goal “get n% of Y” where Y can be customers, dollars, or some share measure. It is also not “get these 5 features done”. Those are potential measures of success but not the headline of a plan. The headline of a plan is a solution to a problem—whether customers expressed pain (an articulated need) or the team is anticipating a solution (unarticulated need).
Second, the plan is a team effort. Even developing the plan takes a coordinated effort across the team. One way to talk about this is that a plan is not any one of “top down” (executive handed on down) or “bottom up” (crowd sourced), using the classic description of top, middle, bottom. Rather planning is a process that requires a coordination of top down, bottom up, and middles-out. The best plans are the plans that have the best ideas from the broadest set of folks contributing to building the product.
Third, one might be tempted to look at this as a PowerPoint outline and do a slide on each one. A lot of plans get made that way :-) The only approach to planning is to write down the plans in words, Word, and to go through a process of making sure there is a consistent voice to the plan. That process of writing down the plan is just as important as the ideas within the plan. Perhaps the topic for a future post.
Building a bridge
As the team comes together with a shared understanding of topics such as those above, the next step is one that can be taken together. There are two key parts of the plan that really bring together the context and help to bridge the “engineering plan” and the “social science instinct”.
- Big Bet(s). Every project is made up of one or two significant bets. These can be new technologies, break from the past, or new product area. These are the parts of a product that go beyond the incremental improvement (relative to your own previous release or to competitive products viewed in the same space). Detailing these up front is a really helpful tool because it means that there aren’t any other big bets. Big bets are generally the immutable parts of a plan–the plan doesn’t really hold together without the bet and it isn’t likely that part-way through a project you could add another big bet. So big bets serve as a foundation upon which future choices and decisions about a project can be made. It is tempting to have a lot of big bets, but even the largest projects cannot really sustain more than a couple–remember once the team commits to a big bet the idea is that it needs to get done no matter what or said another way, the soul of the product rests on getting this part “right”.
- Engineering plan. The engineering plan can be thought of as a feature plan but is better thought of as a scenario plan when viewed through the eyes of engineering. When viewed through the eyes of the sales and marketing members of the team, an engineering plan should read like a “we solved these problems” which can relatively easily get translated into the “story” of the product/service or the “positioning”. It is a good idea for the engineering plan to be separate from the organization chart and to really represent the cross-team efforts (if that is applicable). Even the most straightforward app these days is a front-end/app/UI and a back-end/service and those are often teams (or people). Making sure the product goals are expressed as what those do together, not what they do independent of each other, will also help to bridge the engineering plan and ultimately the business and marketing strategy.
There are many more parts to a plan–the business plan itself, the marketing plan, the PR plan, the pricing structure, the materials to train support and sales people, the operations / scale out plan, the test plans, the self-host plans, and so many more. The above represents some tools that the whole team can potentially benefit from if the work is done before the project really starts. As teams get into rhythms more things can be done up front and together. This is just a framework for when the first goal is getting folks on the same page to build something.
As much as we’d like, there is no magic answer or formula. If there was, then all projects would use it and would just be well-executed. No product is developed twice, so our collective ability to experiment and to design/iterate on a specific instance of product development is limited. All we each have is experience and paying close attention to the context and here and now when developing a product.
PS: Thank you for reading. This was a first post in this blog–a learning process. I welcome feedback on the tone, structure, and approach. These are complex topics and I’ll probably see the shades of grey or middle ground more than the “answer”. Let me know what you think.
PPS: This post is about the general topic discussed and is not about anything specific in the past or present.