Learning by Shipping

products, development, management…

Posts Tagged ‘tension

Combining guessing and planning in product development

with 14 comments

Mission: Impossible movie frameAt 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.

Challenges

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.

Image that represents the difference between local and global optimization.  There is an x and y axis showing conceptual peaks and valleys in product development.  The current "you are here" position is a low point.  Local optimization is shown as a positive peak.  Global optimization is an even higher positive peak.

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.

–Steven

###

Written by Steven Sinofsky

March 11, 2013 at 1:00 pm

Posted in posts

Tagged with , ,

Dealing with doubt and over-confidence in building something new

with 15 comments

Walking the new product development tightrope between confidence and doubt.  Symbolized by a woman walking a tightrope across a big city skyscape.When you’re creating a new product or service, whether as a startup or within a big company, you’re going to be faced with doubters from every direction.  People on the team, your boss, your peers, your investors, friends, family.  Even when the first outsiders see the product they will probably be more doubtful than supportive.  The most important thing is to avoid doubting yourself.

If you thought up the idea, got funding or approval to go forward then persevering is a key part of getting the work done.  The doubting you’ll most certainly get can feel almost crippling.  In the extreme it turns into those increasing moments of self-doubt and ultimately a loss of confidence.  That self-doubt can prevent new ideas, new products, from growing to success.

The converse of this behavior is to dig your heels in and to just stubbornly move ahead as though no one has expressed any doubt.  You’re getting stuff done.  As things progress there’s a good chance you’re increasing the distance between you and your early supporters-but-doubters.  That over-confidence can prevent new ideas, new products, from making small but necessary changes that can substantially increase their chances for success.

Finding the right balance between caving in and stubborn is something everyone can work on.  There’s no right answer, but you can look for signs or signals that your balance needs some tuning.

5 ways to doubt

Doubts are going to be everywhere in a new venture.  In new products there are a few common doubts that you should be mentally prepared to hear.  If you know these are coming you can use that as a chance to consider how you are going to engage in a discussion about that sort of doubt—not how you dispense with or handle the doubt, but how you can talk about why you might have a different point of view.

  • Been done before.  Very few new products are “new to the world inventions”.  Even things that are new to the world often solve pretty well-known problems.  In reality most all products are incremental when you step back and consider the full context and landscape.  From Velcro® to the Swiffer ® to Facebook and Instagram, these products were incredibly innovative but by and large the innovation amounted to new combinations of some new technologies aimed at solving somewhat known problems.  You can get yourself in quite a spiral if you think your product needs to be an invention versus an innovation.  Thinking about your innovation and value delivered can help you through this.
  • Just a feature.  In new services in the tech industry we constantly see people saying that a new product is “just a feature”.  There’s always some truth to that, but it is because it has to do—as a consumer you don’t want every service that comes along reinventing everything around the social fiber for example and as a company you don’t want to spend resources on work outside your value proposition.  Finding the balance between your unique perspective and value and simply adding all the stuff around your value is something to work through and be clear about.
  • No one wants that.  The focus group of one is both your biggest asset and biggest liability in building a product.  If you let one person, from your best friend to your spouse to your boss, convince you that no one wants a new product then too many ideas will fail to make it to fruition.  As the person taking the risk to seek funding or get approval for an idea, you owe it to yourself to keep pushing.  When the focus group of one is yourself and you’re taking the risk that is the very definition of entrepreneurial thinking.  You saw a problem, an opportunity, or a solution.  There’s always a time to take a step back but at the early stages a focus group of one that is yourself is pretty important.
  • Priced wrong.  All new technology products are going to be either too cheap or too expensive.  If you’re building a new device, it will always be too expensive in the early stages because the industry is, as we all know, based on economies of scale.  A new service or app is always going to struggle to simply charge people or find space for advertising from the start.  Too cheap/too expensive is going to happen.  Rather than just punt or just restate the known answers (from it will scale to freemium) perhaps you can differentiate your answer to these concerns with some novel or detailed thinking.
  • Doesn’t fit with strategy.  In a large organization you are, with 100% certainty, going to run up against “strategy” as you propose your new idea.  This can be a frustrating experience to a champion of a new idea (or new way to solve a problem).  You can throw up your hands in a huff.  You can claim “innovator’s dilemma”.  You can talk about stifling bureaucracy.  The important thing to do during this doubting moment is to be informed about these strategic issues.  These are real to a large company because a strategy is a unique part of what a large organization delivers to customers—it is more than a collection of products, but the relationship and between them and reasons they are offered.

5 ways to be over-confident

While many from the outside will be doubting you, the most important thing to do is overcome your natural reaction to dig your heels in and be stubborn.  When doubt is expressed it is your chance to engage in a dialog and to calmly evangelize your idea while hearing the doubt as feedback.  We all know that when you’re pushing a new idea there are things to do better.  This is especially true when you’re in the early stages and developing your “story” as to why the idea should get turned into a product.  What are some things you might be over-confident about that the doubters might actually be saying?

  • Wasn’t clear.  In talking about a potential new product the most common challenge is a problem between your brain and your mouth or keyboard :-)  In other words, as crystal clear as the ideas are in your head, when you say them or write them down it just seems like other people are not “getting it”.  Your own excitement and enthusiasm, or your own “ah ha” moment, isn’t getting translate into a pitch or description that others can grok.  After the third or fourth person saying they are confused or your conversations are “all over the map” then maybe you should take a step back and work on the description and story behind the idea?
  • Didn’t study the competition.  When folks say an idea isn’t new or has been done before, then it could be that you are not expressing the unique attributes of your idea in a compelling way or perhaps your unique attributes are not unique enough (or valued).  It could also be that you’re not expert enough on the competition.  Maybe in your excitement you missed a competitor or you dismissed a competitor too quickly?  Keep in mind the competition isn’t standing still so maybe things have changed from when you looked?
  • Design is weak.  Software products often get pitched before the design and flow of usage are understood.  For a product that is solving a known problem in a new way, the design is a critical element of what you’re offering.  In that case it really isn’t enough to pitch the idea as “don’t worry we’ll do a better design later” because your design is integral to the offering.  For any product that is entering a commodity space with a new twist on uniqueness (branding, distribution, pricing, bundling, etc.) the design of those elements (yes pricing can be designed) need to be more than sketches since those aspects are key to what you’re doing.  Without that level of detail you might be missing the crux of the doubt.
  • Trying to do too much.  “Boiling the ocean” is a common refrain when experienced people see an idea for a product that involves touching many known areas of existing products.  If you’re service starts off with the need to build out a whole infrastructure before you can even start to show your unique value or if you have a feature list a mile long, then there’s a good chance the doubt is not focused on your idea, but on the scope of what you’re trying to do.  Everyone loves big ideas, but rebuilding the world as the pre-requisite is a sign that you can do a better job scoping the first milestone or so of work.
  • Clinging to the wrong elements.  Many times in talking about an idea and in the early stages, every single choice you make is critical.  As the one originating the idea you tend to think of your product as a finely balanced set of decisions, each carefully interrelated.  As things progress, you owe it to yourself and doubters to make sure you are revisiting some choices.  Do you really need that architecture?  Is that UI widget really that important?  Is it critical that you have that feature?  In most every new product you can see something that you know was an early choice and doesn’t quite fit anymore.  Be the person leading the charge to back out of choices that are no longer key to delivering the value proposition.  You’re in a unique position to decide what can really go.

Keep in mind

From the moment you think up an idea until the first working models/prototypes are used by potential customers you’re going to run into doubts from all corners.  It is easy to lose confidence.  It is easy to become over-confident.  Balancing these two extremes is an important part of being brave enough to keep pushing forward.  New ideas can’t get turned into products without the skills to navigate this complex and emotional stage in product development.

Two things are always part of these early stages and important worth keeping in mind.

First, validation is hard to come by.  You will get tons of support and even encouragement from those around you.  But validation won’t come for a while.  Hang tight.

And second, product development is hard.  No one said building a new product or getting a big company to break into a new business (or redo an old business) is easy.  There are no right answers.  There’s no certainty.  Doubts come from shaking things up.

–Steven

###

Written by Steven Sinofsky

February 27, 2013 at 7:00 am

Posted in posts

Tagged with , ,

Engineering and social science lead to plans

with 140 comments

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.

–Steven

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.

###

Written by Steven Sinofsky

January 5, 2013 at 9:30 am

Posted in posts

Tagged with ,

%d bloggers like this: