Blog Posts

Good Enough

Blog: Tyner Blain

View of diminishing returns

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.

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.

Three Perspectives

Three perspectives on product creation

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 lead 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:

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.

diminishing returns in a kano

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

good enough vs. more-is-better

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.

diminishing returns of benefits of fuel efficiency

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.

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="http://www.businessprocessincubator.com/content/good-enough/?feed=html" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples

BPMN.org

XPDL.org

×