How to Write Product Requirements Iteratively

Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery.

You have an idea. You write it down. Maybe you sketch it on a white board. You talk to some engineers. You write user stories. And away you go. You start building.

That sounds right. Isn’t that what we are all doing?

It’s what many of you are doing. And it’s exactly why your requirements are garbage.

Don’t get me wrong. This isn’t a post about understanding the problem you are solving, or where ideas come from. It’s not about understanding your market, your users, or even your business.

This post is going to assume you’ve done all the right work, that your idea is good, and that you have a clear understanding of what needs to be built. Instead, we are going to focus on why even given all of that, your requirements are likely still garbage.

Just like in writing anything, to avoid producing garbage, you need to take an iterative approach.

When Writing Product Requirements, Start With a Terrible First Draft

Anne Lamott in Bird by Bird writes about being okay with a terrible first draft. She focuses on just getting the thoughts and ideas down on paper. When you don’t have to worry about whether or not it’s good, you can simply focus on getting it all down. You turn off the internal critic and your creative juices flow.

This doesn’t just apply to writing. It applies to sketching product ideas on a white board. It applies to drafting user stories.

If you think visually, start on a white board. Imagine what an idea might look like before you think through how it works. But don’t stop there.

Once you have a rough idea of what an idea looks like, draft user stories. You will likely find that the linear process of writing things down, raises new issues that you didn’t uncover at the whiteboard.

Does It Actually Solve the Problem You Identified?

Once you’ve got a rough sketch and some semblance of user stories, ask yourself, does this solution solve the problem you are tackling?

This may seem like an obvious question. Aren’t you designing a solution in the first place? It’s not an obvious question. Many times you will get caught up in an idea. The idea will evolve. You’ll get distracted by what’s cool. In the end, you might end up with something that doesn’t actually solve your problem.

So always stop and ask yourself, does this solve what you set out to solve?

If the answer is no, try to tweak it so that it does. If you need to, start over.

If the answer is yes, move on to the next step.

Can You Simplify It?

More often than not, your solution is going to be a complicated mess. That’s okay. This is a necessary by-product of working through how the problem can be solved.

However, it’s not okay to ask your engineers to build a complicated mess.

This is  exactly why your requirements are garbage. You are finishing the requirements process way too soon.

Instead, keep going. Ask yourself, how can you simplify this solution? What can you take away without impacting the integrity of the solution?

Now while this process is like editing a paper, I want to be clear, you aren’t merely editing the words you use to describe your solution. You are refining the solution itself.

This is where you want to question all of your assumptions. For each component of your solution, ask yourself, what would happen if you removed this? Can you skip a step altogether? Push the boundaries. Cut as much as you can.

How will you know if it works?

Once you’ve simplified your solution as much as possible, ask yourself, how will you know if this solution works? How are you measuring success?

This can be hard and merits a blog post in and of itself. But let’s assume that you identify a metric that will tell you whether or not your solution is working.

Revisit each and every piece of your solution. Does it move that metric? If not, why are you building it? Refine and simplify again.

Sleep On It

By now, it’s going to feel like you have a pretty good solution. And you might. But don’t send it over to engineers just yet.

First, sleep on it. Sleeping on it allows your unconscious brain to tackle the problem. Don’t skip this step. It might sound silly, but it works.

Simplify Your Product Requirements Again

The next day, after your unconscious brain has had time to work through your solution, revisit the same set of questions.

• Does your solution solve the original problem?
• Can you simplify your solution?
• How will you know if it’s working?

Make any necessary adjustments and refinements. You will be amazed at the things that you see today that escaped you yesterday.

Talk Through Your Product Requirements With Someone Else

Finally, spend some time talking your solution through with someone else. Sometimes the simple act of talking it through out loud forces you to see things that you’ve missed up until this point.

Another perspective will also help you see the things that you you can’t see on your own. Someone else may be able to question an assumption that unravels the whole solution or better yet, simplifies it even further.

Who should you talk it through with? Anybody. Your neighbor. Your engineers. A real-life customer. Your designer.

You’ll get value out of talking it through with anybody. But you gain additional benefits by talking it through with specific people. Engineers will be able to point out things that are technically challenging. Your designer is a great resource for helping you simplify. A real-life customer is the best judge of whether or not it actually solves your problem. So talk it through with the people around you.

Bring Discipline to Your Product Requirements Writing Process

You might think you are already following this process. You revise. You collect feedback. You edit and refine. We all do this to some degree.

But just as IDEO works to get past the first 20 ideas to find the really innovative ones, we also need to keep pushing on our requirements, to find the simplest solutions.

Our job isn’t to solve problems. Our job is to solve problems in the simplest way possible. Doing so increases the chances that our users will understand how to use the solution, reduces the engineering investment to deliver the solution, and allows your product and engineering team to focus on the core of the issue at hand rather than getting distracted by countless features.

So take the time. Draft. Evaluate. Simplify. Understand success. Sleep on it. Simplify again. Talk it through. And finally, build.

How many of these steps are you skipping? What changes are you going to make to ensure that your requirements aren’t garbage? Please share in the comments.