Best-Kept Secrets of Product Development: Plan to Build Less

Best-Kept Secrets of Product Development — Part 1: Plan to Build Less

Image from https://akvo.org/blog/the-key-to-users-happiness-story-mapping/

Here are some of my notes from the Story Mapping book, some that are just common sense but at the same time, super hard to keep in mind while developing products:

The whole theme is:

Plan To Build Less

This sounds controversial for many engineering teams that their “Performance” is measured by “lines of code added” or “user stories released” but if accept that the goal of a software engineering team is to “Change The world!” then this changes the way we look at our “performance” and what we consider “productive”!

So here we go, the magical best-kept secrets of product development all with focusing on “Planning to Build Less”

There’s always more to build than you have people, time, or money for. Always.

In the old-school approach to software development, when we’d find that new stuff later on — after we’d already estimated delivery time and committed to a delivery date — we’d call that new stuff scope creep. But the reality, is scope doesn’t creep; understanding grows.

Focus on what you hope will happen outside the system to make decisions about what’s inside the system.

Focus on outcomes — what users need to do and see when the system comes out — and slice out releases that will get you those outcomes.

To Software Engineers; Your job isn’t to build software, it’s to change the world. The hard part is choosing which people you want to change the world for, and how.

Focusing on specific target outcomes is the secret to prioritizing development work.

If you don’t know what your target outcomes are — the specific benefits you’re trying to get — then prioritization is close to impossible.

Don’t Prioritize Features — Prioritize Outcomes

Behind outcomes are specific behavior changes for specific people engaged in specific activities

Many times I, and the teams I’ve worked with, have placed all our ideas about the perfect product into a map and been overwhelmed by the amount of work we’d have if we created it all.

It all seems important. But then we step back and think about the specific people who will use our product, and what they’ll need to accomplish to be successful.

A simple prioritization model:

Differentiator: A feature that set them apart from their competition.

Spoiler: A feature that is moving in on someone else’s differentiator.

Cost reducer: A feature that reduces the organization costs.

Table stakes: A feature necessary to compete in the marketplace

Some secrets about MVP (Minimum Viable Product)

Bad MVP definition: Minimum viable product is not the crappiest product you could possibly release.

Good MVP definition: The minimum viable product is the smallest product release that successfully achieves its desired outcomes.

The minimum viable solution is the smallest solution release that successfully achieves its desired outcomes.

When we slice out a bunch of software functionality and call it a minimum viable solution, we don’t really know if it is.

The problem with outcomes is that you can’t really observe them until things come out. When you slice out a release, you’re forced to hypothesize what will happen.

MVP: It’s no wonder that the “crappiest product you could possibly release” definition still thrives. Because that’s the one we don’t need to guess about.

Eric Ries MVP definition: A minimal viable product is also the smallest thing you could create or do to prove or disprove an assumption.

All these above “secrets” are from the amazing “User Story Mapping” book by: Jeff Patton!

If you enjoyed these little secrets, I recommend getting his book so you don’t miss out on all the great stuff he talks about in the book:

User Story Mapping by: Jeff Patton

If you liked this article, click the👏 below so other people will see it here on Medium.

Let’s be friends on Twitter. Happy Coding :)

Cheer!