Good Enough

We hear a lot about building products which are “good enough” or “just barely good enough.” How do we know what “good enough” means for our customers? No one really tells us.

Different Perspectives of Good Enough

There are several important ways to think about a product being good enough – for this article, we will limit the context for discussion to “good enough to ship to customers” or “good enough to stop making it better (for now).” Determining good enough informs the decision to ship or not. Otherwise this is all academic

There are several perspectives on good enough which are important – but don’t help product managers enough. The body of work seems to be focused on aspects of goodness which don’t help product managers to make the prioritization decisions which inform their roadmaps. They are important – they are necessary but not sufficient for product managers. Here are some pointers to some great stuff, before I dive into what I feel is a missing piece.

• Good enough doesn’t mean you can just do 80% of the coding work you know you need to do, and ship the product – allowing technical debt to pile up. Robert Lippert has an excellent article about this. Technical debt piles up in your code like donuts pile up on your waistline. This is important, although it only eventually affects product management as the code base becomes unwieldy and limits what the team can deliver – and increases the cost and time of delivery.
• Be pragmatic about perfectionism when delivering your product. Steve Ropa has an excellent article about this. As a fellow woodworker, his metaphors resonate with me. The key idea is, as a craftsman, to recognize when you’re adding cost and effort to improve the quality of your deliverable in ways your customer will never notice. This is important, and can affect product managers because increasing the cost of deliverables affects the bang-for-the-buck calculations, and therefore prioritization decisions.

With the current mind share enjoyed by Lean Startup and minimally viable products (MVP), there is far too much shallow analysis from people jumping on the bandwagon of good ideas without fully understanding the ideas. Products fail because of misunderstanding of the phrase minimum viable product.

• Many people mis-define product in MVP to mean experiment. Max Dunn has an excellent article articulating how people conflate “running an experiment” with “shipping product” and has a good commentary on how there isn’t enough guidance on the distinction. This is important for product managers to understand. Learning from your customers is important – but it doesn’t mean you should ship half-baked products to your market in order to validate a hypothesis.
• MVP is an experimentation process, not a product development process. Ramli John makes this bold assertion in an excellent article. Here’s a slap in the face which may just solve the problem, if we can get everyone to read it. MVP / Lean Startup is a learning process fueled with hypothesis testing, following the scientific method. Instead of trying to shoehorn it into a product-creation process, simply don’t. Use the concept to drive learning, not roadmaps.
• “How much can we have right now?” is important to customers. Christina Wodtke has a particularly useful and excellent article on including customers in the development of your roadmap. “Now, next, or later” is an outstanding framework for simultaneously getting prioritization feedback and managing the expectations of customers (and other stakeholders) about delivery. My concern is that in terms of guidance to product managers, this is as good as it gets. Most people manage “what and when” but not “how effectively.”

Three Perspectives

There are three perspectives on how we approach defining good enough when making decisions about investment in our products. The first two articles by Robert and Steve (linked above) address the concerns about when the team should stop coding in order to deliver the requested feature. There is also the valid question of if a particular design – to which the developers are writing code – is good enough. I’ll defer conversation about knowing when the design of how a particular capability will be delivered (as a set of features, interactions, etc) for another time. [I’m 700 words into burying the lede so far].

For product managers, the most important perspective is intent. What is it we are trying to enable our customers to do. Christina’s article (linked above) expertly addresses half of the problem of managing intent. Note that this isn’t a critique of her focus on “what and when.”

We need to address the question “how capable for now?”

How Capable Must it Be for Now?

Finally. I wrote this article because everyone just waves their hand at this mystical concept of getting something out there for now and then making it better later. But no one provides us with any tools for articulating how to define “good enough.” Several years ago I wrote about delivering the not-yet-perfect product and satisficing your customers incrementally – but I didn’t provide any tools to help define good enough from an intent perspective.

Once we identify a particular capability to be included in a release (or iteration), we have to define how capable the capability needs to be. Here’s an example of what I’m trying to describe:

• We’ve decided that enabling our target customer to “reduce inventory levels” is the right investment to make during this release.
• How much of a reduction in inventory levels is the right amount to target?

That’s the question. What is good enough?

Our customer owns the definition of good enough. And Kano analysis gives us a framework for talking about it. When looking at a more is better capability, from the perspective of our customers, increases in the capability of the capability (for non-native English speakers “increasing the effectiveness of the feature” has substantially the same meaning) increases the value to them.

We can deliver a product with a level of capability anywhere along this curve. The question is – at what level is it “good enough?”

Once we reach the point of delivering something which is “good enough,” additional investments to improve that particular capability are questionable – at least from the perspective of our customers.

Amplifying the Problem

Switch gears for a second and recall the most recent estimation and negotiation exercise you went through with your development team. For many capabilities, making it “better” or “more” or “faster” also makes it more expensive. “Getting search results in 2 seconds costs X, getting results in 1 second costs 10X.”

As we increase the capability of our product, we simultaneously provide smaller benefit to our customers at increasingly higher cost. This sounds like a problem on a microeconomics final exam. A profit-maximizing point must exist somewhere.

An Example

Savings from driving a more fuel efficient car is a good example for describing diminishing returns. Apologies to people using other measures and currencies. The chart below shows the daily operating cost of a vehicle based on some representative values for drivers in the USA.

Each doubling of fuel efficiency sounds like a fantastic improvement in a car. 80 MPG is impressively “better” than 40 MPG from an inside-out perspective. Imagine the engineering which went into improving (or re-inventing) of technology to double the fuel efficiency. All of that investment to save the average driver $1 per day. This is less than $2,000 based on the average length of car ownership in the USA.

How much will a consumer pay to save that $2,000? How much should the car maker invest to double fuel efficiency, based on how much they can potentially increase sales and/or prices? An enterprise software rule of thumb would suggest the manufacturer could raise prices between $200 and $300. If the vendor’s development budget were 20% of revenue, they would be able to spend $40 – $60 (per anticipated car sold) to fund the dramatic improvement in capability.

One Step Closer

What good enough means, precisely, for your customer, for a particular capability of a particular product, given your product strategy is unique. There is no one-size-fits-all answer.

There is also no unifying equation which applies for everyone either. Even after you build a model which represents the diminishing returns to your customers of incremental improvement, you have to put it in context. What does a given level of improvement cost, for your team, working with your tech-stack? How does improvement impact your competitive position – both with respect to this capability and overall.

You have to do the customer-development work and build your understanding of how your markets behave and what they need.

At least with the application of Kano analysis, you have a framework for making informed decisions about how much you ultimately need to do, and how much you need to do right now. As a bonus, you have a clear vehicle for communicating decisions (and gaining consensus) within your organization.