How to Write Detailed Product Requirements without Killing Creativity
By: Nathan Udren
Tags: Outcome Over Output, User Stories, Startup, Product Management, Empowerment

Fast-forward to my needs as a product manager, primarily keeping the team focused on building high quality software that is valuable to users. As a PM, the more I know about my users the better. If my team has done thorough discovery, prototyped a solution, and validated UX with users, we have a pretty good idea of what we need to build to create value. That being said, during validation, there are many aspects of a prototype that don’t get a lot of positive or negative attention. It’s not worth our time to validate every single design decision that is made. A fair amount of the user interface is only there to support an important user outcome. When writing BDD acceptance criteria to the level of detail needed to ensure quality, this reality can get lost.

There is a wide gap between the level of detail that we know will add user value, and the level of detail needed to keep cross-functional teams aligned to build high quality software. When we write user stories that pretend that everything is valuable to the user, we are blurring the lines between what we really know and what we are assuming. It doesn’t make sense to me that a fully fleshed out backlog fails to distinguish between the things that really add user value, and those that just connect the dots. Take the user story from earlier:

“As a user, I want to be able to enter my credit card so that I can check out”

At first glance, we might take this story for granted because we have all used apps that behave this way. Looking a little deeper, we can see that this story only adds value in that it lets a user complete an order. As a user, I don’t actually want to enter my credit card. I’d probably prefer not to pay if given the choice. All I really want to do is acquire whatever is being sold. So why do we pretend the user wants things that they don’t. Just so we can write clear acceptance criteria?

When we need to make changes to our solution due to technical constraints, new knowledge about our users, or when someone just thinks they have a good idea, this loss of focus on user value can lead to poor decisions. It’s too easy to come up with ideas that look like a good, but don’t actually deliver value. In this case, it would be me the PM who needs to be the bad guy and shoot down these unfocused ideas.

Instead, with the right amount of context the story helps the team understand what problem they are actually trying to solve. (The right amount of context is a lot of context.) The following is an arbitrary example. The format of the context is not as important as the content.

Outcome Convert active trial users to paid plans

Key Results Target 65% conversion of trial users to paid users Epic As a business, I want to be able to collect payments so that users can access premium features

Assumption Users find premium features sufficiently valueable to purchase

Evidence 90% of people surveyed showed in interest in the product

Evidence 70% of prospects signed up on landing page

Assumption Users prefer one time in-app purchase for premium features Epic As a user, I want to be use a convenient payment method so payment is as painless as possible

Evidence Payment data from previous products with similar market indicate that there are 5 different payment methods that are used by at least 10% of users

Metric Target 90% of users who reach payment method selection should continue to payment Story As a user, I want to be able to pay with Visa so that I can complete my purchase

Metric Target 90% of users to start paying with Visa should complete purchase

Scenario User pays using Visa

Given a user has created a valid order

And entered a valid Visa credit card number in the credit card number text field

When the user presses the “pay” button

Then the user should see a payment confirmation message

In the first case, we make an assumption about what is valuable to a user, but in the second case, the layers of value described allow us to be thoughtful in ways that may be more helpful to a user. For example, let’s suppose we find that a large portion of our users are not completing payments. Using only the individual story, we might conclude that the payment screen adds too much friction and decide to prototype a credit card scanner that allows users to take a picture of their card and have the details automatically populated. Sounds like a good feature, but does it really address the most valuable opportunity? If we used the more contextual story, we can trace user value all the way up to the top and see that users are interested in acquiring our product. We might decide to test a subscription model instead.

If a backlog with detailed acceptance criteria cannot find ways clearly articulate where value is coming from, the PM is always going to have a hard time saying yes to new ideas. It’s up to the PM to define requirements in a way that hones their team’s creativity rather than confusing it.

So what can we do differently?

The answer, in short, is nesting. When splitting stories and epics, instead of tossing all the stories into a bucket, we can keep the nested structure that maintains the context with which all our stories were conceived. Tree structures are used for similar purposes in other situations. For example, one of the first mental models I encountered when transitioning into a PM role was the Opportunity Solution Tree as presented by Product Talk’s Teresa Torres. It’s a very simple yet powerful way to trace value all the way from desired outcomes to experiments.

Though the opportunity solution tree is meant to support continuous discovery, the same concept can be easily applied to a backlog. The resulting backlog structure should look something like this: