Best-Kept Secrets of Product Development Part 2: Plan to Learn Faster

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

Here are some of my notes from the amazing “User Story Mapping” book by: Jeff Patton!

Most of these when you read them sound like just common sense but at the same time, super hard to keep in mind while developing products:

The whole theme is:

Plan To Learn Faster

This sounds controversial for many engineering teams specially in established companies to put out a product to “Learn” or “Learn Faster”.

Specially if that means you put experiments out there for users to try, and those experiments are not 100% functional software!

So how do you convince the leadership that you need to learn? How do you bring up the fact that, if an a high level executive in the company believes that customers “want” or “would love” a certain software, they could be totally wrong!

In fact there are studies that shows that more than 80% of good ideas don’t work!

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

One of the hard parts of being a product owner is taking ownership of someone else’s idea and helping to make it successful, or proving that it isn’t likely to be.

The best product owners, help their entire team take ownership of the product.

Product owners won’t start their work by building a backlog of user stories. They started with the big idea someone had, and treated it like an opportunity for their company — because it is.

Here are some of the things that Product Owners should discuss with the team and the people with the “big ideas”

Who are the customers?
Who are the companies we think would buy the product?
Who are the users?
Who are the types of people inside those companies we think would use the product, and what would they be using it for?
Why would they want it?
What problems would it solve for customers and users that they couldn’t solve today?
What benefit would they get from buying and using it?
Why are we building it?
If we build this product and it’s successful, how does that help us?

Product Owners needed to build shared understanding with others in his organization before they could take ownership of the opportunity.

Your team’s first story discussion is for framing the opportunity.

Product Owners trust their leadership’s intuition, but they knows that this big idea is a hypothesis.

Product Owners know the only way to be sure the idea will succeed is when they actually see it succeed.

Validate that the problems you’re solving really exist.

While Product Owners has been talking with customers and users, they have been building up a pool of people they think are good candidates to try his new software. Some companies refer to these people as customer development partners.

Because Product Owners are really smart, the last thing they’re going to do at this point is to build software. Sketch and prototype so they can envision their solution. Prototype and test with users to learn whether your solution is valuable and usable.Watch Out for What People Say They Want.

They knows the people who said they’d like it and use it are just guessing, too. Treat every release as an experiment and be mindful of what you want to learn.

Our goal isn’t to get something built; rather, it is to learn if we’re building the right thing. It just so happens that building something to put in front of customers is one of the best ways to learn if we’re building the right thing.

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!