Today’s problem shouldn’t be tomorrow’s. Define the requirement.

A product manager is the person responsible for communicating the product vision from the idea owner to the development and implementation teams. Their primary role is the make the product valuable, usable and feasible but to get to this stage they will often encounter problems. What we class as a problem can vary wildly; as Jay Z famously put it he’s got ninety nine problems but a … ain’t one. However problems that might resonate more closely with a product manager could be a backlog that never relents, a lack of clarity or high expectations on your work or throughput. However the type of problem shouldn’t matter too much as what will be discussed is applicable to all. This post aims to offer a high level overview on how to capture the real requirements from the beginning as well as how to display them to others.

“The key is this: Meet today’s problems with today’s strength. Don’t start tackling tomorrow’s problems until tomorrow. You do not have tomorrow’s strength yet. You simply have enough for today.”
Max Lucado

While it is important to learn from our mistakes dwelling on the past can prove costly, especially given the current rate of change. You definitely don’t want to be performing rework on your drudgery and you certainly don’t want to be squandering your time on someone else’s right? Patience is a virtue as they say and boy doesn’t that saying ring true in software development. But by being sandwiched in-between business owners and users product managers are required to act swiftly and in doing so we often deploy with haste. It is a disheartening cycle, you thought you managed to move on from the work item but sadly like rain in the UK it just keeps coming back. So let’s start at the beginning to see how clearly defined requirements can help you with your struggles.

Start with the user
As basic as it sounds starting with the user underpins this whole process. You will be wasting your time without an understanding of how a user interacts and their underlying needs. A simple but powerful technique we use here at ucreate is called user story mapping. This is the process by which we map out the complete user experience starting at the earliest possible interaction right through to the last. Find a whiteboard, pack of sticky notes and a pen and give it a go yourself. Start with how they will find the solution and carefully think about the interactions they will take at each step. You should move from left to right and by the end it should resemble the possible user interactions through your solution.

Once the user interactions have been mapped out you now need to think carefully about what the user will need in each of these steps. No matter how trivial make sure you note it, an action button is a good place to start. Now visualise this, you can see not only the interactions but also the configurations at each point. Already you have managed to define and expand your requirements from item X down to item X.1, X.2, X.3. The potential scale of your project is being laid out in front of you. Don’t worry too much at this stage whether you have captured all items as they change and even more so when you have real data to work from. This is your first problem; you now have to whittle this down into what is known as an MVP.

That is where the next technique we adopt here at ucreate comes in, MOSCOW. This is where you will need to put yourself in the shoes of the user, ideally using a persona. It is time to ask yourself what do you really need? Initially you can use colours, symbols or stickers and apply them to your sticky notes but eventually you will want to reorganise your cards into 4 rows titled: Must, Should, Could and Won’t. Remember the goal is to start less to finish more.

At this stage you shouldn’t concentrate on anything beyond Should and in an ideal world you concentration would end at Must. You can focus your efforts on the items which add value and ultimately user satisfaction. If you ignore value it doesn’t matter what you finish as you will be building a solution that no one wants. This is a common problem in waterfall development but in the agile space it is very much a problem too as Rememberis able to demonstrate. Or if you are lucky and all your features are valuable you have the very real problem of burn or limited runway. QBotix is one of many examples where runway has been the primary cause of failure and Zirtual is one for burn.

As you can see there is a lot of value in utilising a technique such as the above. From the beginning you are only focusing on value, limiting waste and effort expended in a lean approach. A narrow sight also means a higher throughput as efforts are concentrated rather than finding yourself sporadically taking on every task in an attempt to get everything done. But narrowing down the options is only the start of your work now you need to clarify these work items in order to curb problems further.

Writing the requirement

The order in which you address your features comes down a three way standoff between value, risk and effort. This is a business decision but regardless of the order chosen we need to concentrate on providing clarity to those performing the development and testing. Structured writing can provide this clarity and here at ucreate we use behaviour driven development (BDD) as our structure. Working back from the intended behaviour will allow you to define the actions required to accomplish the expected outcome.

Always start with a title, this should be little more than a reference or an identification tag if you will. Next you need to provide a narrative to help explain the reason behind this story. Following this a detailed scenario is required to help visualise the journey your stakeholder will be taking. Finally you will end with the acceptance criteria for this story which depicts the outcome you are trying to achieve and those you want to avoid. Below is a worked example of this in action, give it a go yourself after reading:

1. Story Title — <material reference> ‘Ability to share blog post’

2. Narrative –

In order to <achieve a business goal or deliver value> allow others to know about this article

As a <stakeholder> reader

I want to <something> share this article after reading

3. Scenario — <detailed example> The reader is subscribed to your blog and has found your latest blog post. When the reader has finished reading the post they decide they have enjoyed the content. Usually when they enjoy a blog post they decide to share and this occasion is no exception. They find themselves at the end and now look to the bottom of the post for a sharing medium. Sometimes they are provided with multiple share options to choose from but what they really like to use is LinkedIn, as such this will be the chosen method. The user has identified that the ‘Share’ icon/button is the likely call to action. When selected this icon/button will provide the method which enables them to quickly share the post.

4. Acceptance Criteria –

Given <a context> a reader would like to share the blog post on LinkedIn

When <something happens> the reader selects the share icon/button located at the bottom right of the post

Then <expected outcome> the blog will redirect the user to LinkedIn

And <further definition> the subject line will be filled with the blog post URL so that the user can easily share

The importance of this process comes down to visualisation; by providing context and structure to your requirements you are dramatically reducing ambiguity. By mentally walking through each step the reader (developer/tester) is building the bigger picture behind what is required. It also helps to highlight where the value lies, if any exists at all. It provides a means to easily explain your work to others or justify why it should not be started, reducing wasted effort. Initially it can be time consuming but you will reduce the amount of rework that will be enter your system. The focus of this activity is to improve the quality of your work. Think carefully about the type of interaction at each stage and most importantly if your acceptance criteria is too long your story is probably too big. For a more comprehensive read on this structure try BDD In Action by John Smart.

A final thought, get user feedback as soon as possible on each of your builds. This either means allowing them to use your test environment or biting the bullet and pushing to live. User feedback is far more meaningful than guesswork; it provides the perspective that ultimately puts the pounds in your pocket. And remember, you’ve got ninety nine problems but a requirement ain’t one.