How to Write Detailed Product Requirements without Killing Creativity
Introducing the Outcome-Oriented Backlog
As a former software engineer, I had mixed feelings about user stories. I really appreciated knowing exactly what I had to build, but at times I also felt like a machine trying to build something exactly to spec. I almost relished the times when a product manager would give unclear requirements so I could jump into action and think of a creative solution.
As I transitioned to my current role as a product manager, I wanted to be able to empower my team to think creatively. Once I dove into the complexities of building a product roadmap, I realized that creating great user stories is anything but simple. Documenting detailed specs is important to ensure quality but validating that level of detail is often not feasible or even a good use of time. This means that the a typical backlog contains some value-creating stories and some implementation details. It’s usually not clear which is which. I’d want my team to think creatively and not be bound so strictly by requirements, but when they don’t know what is negotiable and what isn’t, it is very difficult for this to happen.
I am going to explain how, using what I call the Outcome Oriented Backlog, we can actually achieve both detailed requirements, and a clear representation of where we are creating user value. This allows an empowered team to push back on requirements when they identify better ways to deliver user value.
First a bit of background on user stories. They were first introduced in the book Extreme Programming Explained by Kent Beck and popularized by Mike Cohn in User Stories Applied. User stories have become the standard agile tool for describing requirements in a user-centric context. A user story is meant to describe exactly how features will add value to a user.
The structure is:
“As a <type of user>, I want <software capability>, that I can <user outcome>”So for example:
“As a user, I want to be able to enter my credit card so that I can check out”User stories are always defined alongside a “definition of done,” or acceptance criteria. My teams use Gherkin style behaviour driven development (BDD) acceptance criteria because of the ease in which they can be translated to manual and automated test cases.
Gherkin Style Acceptance CriteriaScenario: A user has created an order and wants to pay to complete checkout.
Given a user has created a valid order
And entered a valid 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
As an engineer, I always I appreciated highly specific acceptance criteria that could be translated directly to test cases. In the fast-paced agile world, alignment is key. Software gets very complicated very fast. It’s very easy for things to fall through the cracks. Detailed acceptance criteria allows engineers, QA, product and design to stay aligned on a common definition of the expected functionality. They should not be static; acceptance criteria can be updated fairly often as members of the team negotiate functionality. This is not to say that my engineering colleagues and I were unable to deal with ambiguity, or not qualified to make “product decisions.”
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 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 usersEpic 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 featuresEpic 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 paymentStory 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:
I like to call this the “Outcome Oriented Backlog” because we can clearly see how each piece of work supports a user outcome. Using the Outcome Oriented Backlog, we can map where user value derives. If you ever need to understand why a story is valuable, you can look at its parent. In this way, we can easily understand why each feature and test case is included in a piece of software. We can much more easily evaluate whether our solution is performing well because we understand more clearly what it’s purpose is. This helps the entire team understand what problem they acutally need to solve.
Clearly, changing the structure of a backlog is going to require some fine tuning on how stories and epics are written and how tracking tools are used.
Here are a few tips:
Story vs Epic
It’s important to note here that an epic and a story are very similar. The difference is that a good user story should follow the INVEST criteria. In this case the difference between an epic and story is in the “EST” of INVEST.
Estimable — Stories should provide just enough information so they can be estimated. It is not important to know the exact way that a particular problem will be solved. It must only be understood enough to provide a high-level estimate.
Small — Stories should strive to be granular enough in scope that they may be completed in as little time as possible, from a few weeks to a few days.
Testable — Stories need to be understood well enough so that tests can be defined for them. An effective way to ensure testability is to define user acceptance criteria for all user stories.Epics and stories describe user value the same way, but bigger stories, called epics, should be broken down sufficiently so that they can be estimated and completed in a reasonable amount of time.
Definition of Done for Epics
There are two mode of thinking here:
- An epic is done when all of its children are done.
2. An epic is done when it satisfies the evaluation criteria defined by its parent.
The first is a delivery oriented approach is helpful for making sure work is getting done sprint to sprint. The second is preferable because it is a much more outcome oriented approach. It is very useful when it comes to actually evaluating the performance of features and the product in general. It will help your team drive outcomes rather than features.
Great product development organizations will gravitate towards the second mode of thinking while purely delivery focused teams will gravitate towards the first.
Looser coupling of problem space and solution space
It’s also important to note here that since there is not a 1:1 ratio of user stories to test cases, the stories should not be explicitly linked to the UI. Often, because backlog items are not written until designs have been completed and validated, there is a lot of coupling between designs and user stories. In this case, when designs change, only test cases need to be updated. In this way, it actually becomes much easier for the entire team to negotiate functionality. When a team is actually aligned around where user value is being created, we can empower the entire team to contribute to innovative solutions.
Summary
The value of the Outcome Oriented Backlog is that it enables the entire team to understand exactly where user value is being created and what user outcomes are important. It has the ability to deeply align a team around the why, as opposed to superficially around the what. A structure like this allows detailed acceptance criteria that will support engineering in delivering high quality software, but also empower a collaborative team to innovate in meaningful ways.
Nate Udren is a product manager at TribalScale. He hates writing about himself, but the marketing department made him do it. A proud generalist, he believes that the best ideas come from asking good questions and challenging assumptions. He is passionate about empowering teams to build great products.
