redacted use case dependency thumbnail

Defining and building a good minimum viable product is much harder than it sounds.  Finding that “one thing” you can do, which people want, is really about a lot more than picking one thing.  It is a combination of solving the minimum valuable problem and all of the other things that go with it.  Solving for both the outside-in needs and the inside-out goals is critical.

Starting with Icebergs

image of iceberg showing the massive hidden parts

Rich Mironov’s great article, the DIY Illusion, talks about the importance of focusing your team on building what is important to build (and not building something more easily acquired in other ways).  Imagine your team is building a mobile app.  Now imagine your team is building – from scratch – a CRM system to allow you to track all of the users who install the app.  Or imagine they are building a ticketing system – from scratch – to allow you to track development team progress on feature requests and bug fixes.

context of framing

I introduced the Andy Polaine’s concept of designing in different contexts in an article about roadmaps and feature-lists last year.  The same pattern / concept applies here.

Rich’s article describes a micro-version of the classic buy, build, partner decision. When it is your team making decisions about dev-ops or other infrastructure that they need, this is exactly what it feels like and looks like.

Pop up to the broader organization-level context, and now it is the classic MBA version – do we build a new product to complete our portfolio?  Or do we partner with someone else to include their product?  Or maybe acquiring that partner (or just the product) makes the most sense.

Both of those decisions are firmly in the inside-out side of thinking about product.  What about the outside-in framing?  Your customers are making  buy, build, partner decisions about your product.  How do you make sure the right answer for them is “buy?”

another iceberg - emphasizing what is hidden

An important point in Rich&#8217;s article is that the work you need to do (to roll your own <insert system here>) is much larger than a shallow analysis would lead you to believe.  The same is true about defining a minimum viable product.  You customers will need to solve more than the single problem on which you begin your focus.

Minimum Valuable Problem

I&#8217;m going to spend the next couple weeks talking only about minimum valuable problems, and not minimum viable products, as an experiment to see if it accelerates a change in thinking with my team.  [I dropped the term first in a meeting with executives yesterday (as of when I&#8217;m typing) explaining that our product is focused on completely addressing the minimum valuable problem, and got some head nods but no direct commentary.]  If you want to know the results, ask in the comments on this post.

In my mind, I remember reading Steve Johnson quoting Saeed Khan as saying that a minimum viable product is, literally, &#8220;the least you could do.&#8221;  I hope it&#8217;s true, I love that quote.  I don&#8217;t know if that&#8217;s actually where I heard it, but let&#8217;s make it quotable, and see if some tweets cause the original author to magically appear.  An MVP is literally the least you could do with your #product.

US quarter featuring the state of Texas

Why make the distinction between product and problem?  Two reasons &#8211; one philosophical and one practical.

Philosophical Soapbox

One thing my clients regularly value from me is that I&#8217;m joining their team with a &#8220;fresh set of eyes&#8221; and one thing I bring is an external perspective on what they are doing and plan to do.  It affords me an opportunity to help shift the perspective of the team from inside-out to outside-in.  In other words, being driven by the needs of the market.  At the product-level of context, this usually means being driven by the problems a particular set of users are trying to solve.  Introducing &#8220;problem&#8220; as a totem in many conversations helps reinforce and subtly shift conversations over time.  The longer I work with a particular team, the more I see the results of this.

When people talk about the product they are usually talking about &#8220;this thing we (will) build.&#8221;  That&#8217;s not nearly as valuable for me in assuring product-market fit as if people are talking about the problem we are solving.  I&#8217;m on a team in the early discovery and definition phases.

We get more value from conversations about why someone will use the product than discussions around how the product will work.  We get more value from conversations around how the product will be used than from discussions around how much it costs to make the product.

Practical Thinking

A huge challenge in communication is one best described by a sketch of Jeff Patton&#8217;s from his book User Story Mapping.

three people discovering they don't ACTUALLY agree[for a larger version, buy Jeff&#8217;s book].

When people talk about &#8220;the product,&#8221; in my experience, everyone in the room will happily carry the conversation forward, each referring to &#8220;the product&#8221; with no one clarifying precisely what they mean.

When people talk about &#8220;the problem&#8221; we intend the product to be used to help solve, it is common for the conversation to reiterate, refine, or at least reference which problem we&#8217;re speaking about.

I don&#8217;t know why these play out in different ways, but they seem to do so.  Perhaps we&#8217;ve got a cognitive psychologist in the audience who can shed some light?

Regardless, the minimum valuable problem seems to be something people are comfortable clarifying in conversation.

Solving the Problem

I get to stand on the shoulders of another giant, Gojko Adzic, and his book, Impact Mapping, as my personal product management  jiu jitsu.  Gojko&#8217;s approach helps me very quickly define what it means to my user to solve his or her problem.

By focusing on the outcomes (there are, in fact, many ways to get to this &#8211; I just happen to find Gojko&#8217;s to be compelling), you discover that solving the problem you originally intended to solve may not be sufficient.

Your minimum viable product may be solving half of a problem.  Solving half of a problem is creating half of a product.  There may be cases where this makes sense &#8211; splitting stories, incremental delivery, etc.  But it doesn&#8217;t make sense for very long.

How often are you interested in purchasing half a solution to a problem you&#8217;re facing?  When the brake lights on your car go out, would you ask the mechanic to just fix one of them right now, and schedule a follow-up visit next month to repair the other one?

Defining the minimum valuable problem is defining the minimum viable product.

The minimum valuable problem is one you completely solve.  You may only solve it in a very narrow context or scope.  You may only solve it for a small group of users or a subset of your ultimate market.  You may only solve it adequately, without creating a truly competitive solution.  But for that one customer, in that one situation, you have completely solved it.

Remember &#8211; you grow revenue one customer at a time.  This sounds like a platitude, but reverse the perspective.  That one customer is considering multiple vendors for that one sale.  Will the customer pick the vendor who is mediocre (and also mediocre for other customers), or will the customer pick the vendor who is perfect for them (even if imperfect for other customers)?

The Problems Behind the Problem

dependency map of user stories[larger]

The above diagram is a real view of the dependencies of an ecosystem for a product.  It is blurred out because it is real.  What it shows, in the upper left corner is the &#8220;target problem&#8221; to be solved.  This target is a candidate for minimum valuable problem.

Each connection in red says &#8220;requires&#8221; because for a given user to solve the problem in their blurred out box requires assistance from another user.  That other user then has to solve the problem of &#8220;help the first user.&#8221;  Or it could be that there is an operational context like &#8220;monitor performance of the [first user group] solving their problem, so we can fine tune the solution.&#8221;  When you&#8217;re doing service work, or designing whole-products, you see (or should see) this on every engagement.

In the ecosystem of a complex problem-space, we discover that there are multiple parties associated with adequately solving the user&#8217;s problem.  Each different color of user reflects a different user involved in the solution of the focus problem for the focus user.  This web of interdependent problems is the rest of the iceberg.

onion diagram

An onion diagram for this same problem space allows us to also very quickly see (even with this redacted version) that there are three systems (or system interfaces) through which different users directly or indirectly use our product to solve their problems.

Bridging the Process Gap

These views of the problem space help us assure that we are solving a valuable problem &#8211; which is my preferred definition of a viable product.  As a bonus, they help bridge the gap between the abstract thinking of a product management team and the concrete thinking of the engineering team who will create the solution and the executive team who wants to &#8220;know what it is.&#8221;

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

2 Responses

  1. This design is incredible! You certainly know how to keep a
    reader amused. Between your wit and your videos, I was almost moved to start my own blog (well,
    almost…HaHa!) Wonderful job. I really loved what you had to say,
    and more than that, how you presented it. Too cool!

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

101 Ways supports Abcam to Accelerate Life Science Research

101 Ways helps Abcam digitally transform to better empower life science researchers at a time when it is needed most Technology consultancy 101 Ways today announces that it is working with Abcam a global innovator in life science reagents and tools, to expand its digital services to the life science community. Aiming at developing and delivering a new digital operating

Read More »

Six Actionable Nuggets of Advice for Becoming a First-time Technology NED

If the pandemic has taught companies anything it’s that tech is not something that you put off and think about ‘later’. The last year has seen organisations go through huge digital transformations, whether planned or otherwise. And for those that aren’t technology-based companies, getting the right board-level advice can not only be hard to find, but the difference between success

Read More »

Culture, Skills, and Capabilities // How to become a more data-driven organisation

In our whitepaper “How to become a more data-driven organisation”, we wrote about the five steps that an organisation would need to take, which are: Outcomes: Defining goals and metrics to ensure clear and measurable outcomes Analytics: Implementing and sharing the analytics to improve data-driven decision making Innovation: Testing assumptions through hypothesis testing and learning Data Platform: Gaining new insights

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at contact-us@101ways.com.