Skip to content

Tyner Blain - Scott Sehlhorst
Syndicate content This Feed Powered by FeedBurner.com
Software product success.
Updated: 54 min 9 sec ago

Why Not What – An Example

Mon, 01/05/2015 - 15:02

Obscenely complicated WW2 U-Boat controls

Forbes quoted Steve Jobs as saying “I’m as proud of what we don’t do as I am of what we do.”  This is a really enlightened perspective – and a way to enforce focus from the top down.  Before you can drive a “this goal is more important than that goal” focus, you have to make sure you’re actually focusing on the goals.

The Customer Does NOT Know Best

customer request from the Google Play store

The top review of a mobile phone app caught my attention over the weekend.  I highlighted a section which really provided clarity for me about the difference between building what the customer asks for, and what the customer actually needs.

The app provides food-item nutritional information.  As you might imagine, navigating the tables of information on a smaller touch-screen device (phone or tablet) could be tedious or tricky.  Definitely a place where the user’s experience could be improved.  This user, who likes the app, wrote a request to be able to sort the tables by column – a “faster horse” for the smart phone era.

This reviewer also added some prose to justify the request for sorting – the desire to avoid foods which are bad for him.

The extra information actually allows us to get closer to the “why” – a desire to eat healthy foods – and not fixate on the “what” – the ability to sort the information. I’ve worked with many people who would do something like the following:

  1. Add a story / feature request to the backlog / spreadsheet, to enable users to sort the information in the tables.
  2. Get feedback from other users – “would you like to be able to sort?”
  3. Prioritize and schedule the feature to be built.

This can easily happen because the product manager focused on the “what” of sorting.  It is an easy mistake to make.  The customer asked for sorting, so the customer wants (needs) sorting.  When I asked other customers if they wanted to be able to sort, they all said “sure.”  This is being customer-driven, and outside-in, right?  Wrong.

Being Market Drive Requires Synthesis

If you’re a regular reader here, you’ve already heard 100 times the importance of asking “Why?”  A different question approach, based on Clayton Christensen’s work in The Innovator’s Solution and the Jobs to be Done approach, will simultaneously ask “why?” and initiate the synthesis process.

“What are you trying to do, when you want to sort?”

There may be a much better way to avoid unhealthy foods than giving users the ability to sort.

You shouldn’t stop here, either.

What are you really trying to accomplish, which is driving you to avoid unhealthy foods?

Perhaps the user has a medical condition which restricts their dietary choices, if the goal is to feel better (in order to spend higher quality time with their family).

Conclusion

If you’re trying to build a nutrition-information app with the goal of helping someone feel better, you probably wouldn’t put “sort by sodium level” at the top of your backlog.  Instead you might build an app which asks them how they feel every day, correlates that with what they ate recently, and then warns them when they are about to make historically bad choices (or rewards them for repeated good behavior).

Being market driven is about synthesizing what customers tell you. Your area of expertise is to understand what is needed, based on what is asked for.  The customer’s area of expertise is not in root-cause analysis, abstraction, interface design, and software development – they won’t make directly-useful requests.

Give them what they need, not what they ask for.
Categories: Blogs

Good Enough

Wed, 12/10/2014 - 21:01

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.

  • 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

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:

  • 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.

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.

Categories: Blogs