I’ve been thinking about the software development process. Big, upfront, design and requirements. User research and analysis. Market insights, gained on exploration or over time. Release cadence – how quickly you get, and incorporate, feedback from your customers about your product. How quickly you react to your competitors’ reactions to your actions.
Big and Up-Front
Leander Kahney published the full transcript of an interview with John Sculley, former CEO of Apple, last week. Of particular interest are the discussions about how Steve Jobs is a designer first, CEO second.
He always looked at things from the perspective of what was the user’s experience going to be? But unlike a lot of people in product marketing in those days, who would go out and do consumer testing, asking people, “What did they want?†Steve didn’t believe in that.
The theme of understanding what users want and need comes up repeatedly in the article. A few years ago, Alan Cooper and Kent Beck got in a debate about the merits of interaction-design-driven versus emergent-design software development. Four years later, I don’t accept the premise that you have to choose between the two. You can treat both decisions independently and make the right choice for your team and market.
Thanks Jim Holland (also PM Tribe author), for bringing this article from Wayne Mulligan (guesting on On PM) to our attention today. It’s a great read, and the money-quote from Wayne about going back to first-principles is:
And that’s the biggest lesson I learned here – you can reap all of the benefits of an agile product development approach without following the rules to the letter. It’s the spirit of the manifesto that counts and not the precise implementation.
In the spirit of that reality – I believe decoupling how do you plan? from how do you deploy? is fair game.
The Risk of Being (Big Picture) Wrong
[When you do no upfront analysis at all, you have complete risk of creating the wrong product. The more analysis you do, the more likely you are to create a product that solves the right problems – problems that your target customers, in your target market, are willing to pay to solve. The units in the graphs in this article can be mostly ignored – all you can really capture, when talking generally about this is the trending. The more time you spend understanding your market, the less understanding you gain. There is definitely a law of diminishing returns. This effect is one of the reasons analysis paralysis is so bad. With analysis paralysis, you delay the launch of your product (at some cost), for no appreciable gain.
The two curves are labeled complex market, and simple market. The idea here is that the easier it is to understand your market, the less benefit you get from analyzing it. Complexity can be in the form of competitive concentration, nuances of problems being solved, specifics of the customers for whom you are solving the problem, and even the notion of just how innovative your solution is (think cars, when horses were common, or smart phones in a world of land-lines).
As a product manager, you have to act with imperfect information. Even if you try and uncover every relevant piece of information (which you can’t do), you will misunderstand some things. You will develop a mental model of your customers’ problems – and that model will be wrong. You will also predict competitive responses incorrectly. To top it off, you’ll make mistakes about “what’s next?” for your customers.
That does not mean you should do no analysis – it means you should not do too much analysis.
Not all product managers are equally good at distilling insights from the vapor of nuanced market data. Great product managers will have (correct) epiphanies about the important problems to solve, and the impacts of disruption on the market. Others will not. The better you are at having these insights, the faster you reduce risk – and the faster you reach the point of diminishing returns of additional analysis. Some product managers and markets may require weeks of analysis, others may require days.
The Risk of Being (Execution) Wrong
Another great quote from the Sculley interview:
[Jobs] said, “How can I possibly ask somebody what a graphics-based computer ought to be when they have no idea what a graphic based computer is? No one has ever seen one before.†He believed that showing someone a calculator, for example, would not give them any indication as to where the computer was going to go because it was just too big a leap.
In The Design of Design, Frederick Brooks discusses the debate between empiricists and rationalists. Empiricists, in product creation, emphasize feedback as the means of gaining insight about what your product should be. Rationalists use intuition and deduction to presuppose what a product should be. In the hyperbole of many agile-waterfall debates, empiricists are burdened with the impossibility of designing the right product in advance, while rationalists struggle under the yoke of being wrong from the start and wasting their efforts up until the first failed product release.
Obviously, neither of these extreme perspectives is wholly true – while both have significant elements of truth.
True insights about your market grow stale with time. The damage from erroneous conclusions about your market grows over time. The risk of creating the wrong product grows over time.
[If you released continuously, including getting feedback continuously, you would face the minimal possible risk that the market has changed since last you checked. You would also maximize the opportunities to correct mistaken conclusions – thus minimizing the risk of being wrong.
You reduce the size of this risk by getting feedback. You get feedback by “releasing” your product to customers, either as a prototype or as a product. Jobs (per Mr. Sculley) realizes the catch-22 of not being able to get inputs from others, until they can realize a version of your idea. Sculley attributes the following to Mr. Jobs: “There was no way to do consumer research on it so I had to go and create it and then show it to people and say now what do you think?“
The longer you wait to get feedback, the greater the cost of effort invested in the wrong ideas. The longer you wait to get feedback, the greater the risk that your market has changed since you formed your ideas.
In stagnant markets, where problems and their solutions are well understood, and change happens slowly and competitors don’t innovate, you can release less frequently with less risk. Until someone decides to innovate, and make your market more dynamic. Markets with active competitors, customers who’s expectations change, and problems that evolve are more dynamic. The risk of delays is greater.
Rationalism and Empiricism Can Co-Exist
My experience has been that both concepts – “think before you act” and “fail fast, get feedback” can happily co-exist.
- You can develop an understanding of your market, your customers, and the very real problems they face, before creating a product that solves those problems.
- Introducing a new product / solution into a market changes that market – so you have to revisit what you know at least as frequently as your market changes.
- Even when you understand the problem, you need feedback to know if the product is actually the solution. The greater the “leap,” the more representative your prototype must be for people to give you feedback about the (eventual) product.
What have your experiences been?
18 thoughts on “Cadence Versus Risk”