Writing Market Requirements Effectively

Writing Market Requirements Effectively

Many Product Managers struggle with writing market requirements that are effective in guiding their engineering teams to build the right solution. Whether you are writing requirements for Agile and delivering user stories for the product backlog or writing a more traditional market requirements document, there is one technique that I have found can be very effective.

Engineers Are Great at Solving Problems

It’s what drives them. Coming up with the best possible solution to a problem and building something great is why many of them became engineers in the first place. And the more talented your team is, the more this will be true.

That’s why it’s critical when you are writing market requirements that you don’t dictate specific features and ways that things MUST work. If you do give your engineers explicit feature instructions you are limiting the possible solutions, and oftentimes will end up with a product that is just mediocre instead of incredible.

Instead of telling your engineers what features to build, tell them what problems the customer has that need to be solved.

Paint a picture of exactly what the problem is, how this affects the customer as a pain point and why it is important to them. You can even include examples of how a solution “might” be implemented to help further clarify the problem. But don’t tell them “exactly” what the feature(s) or solution “must” look like. Instead challenge their creativity and see what shows up.

In our Optimal Product Management and Product Marketing in-person and online courses we call this staying in the problem space. Your job is to very clearly present the problem. Engineering’s job is to present a compelling solution that solves the problem in a creative way.

For Example, Say You Are the Product Manager for a Smoke Alarm

You go out and talk to lots of customers and find out that the biggest problem they have with your products (and the competitor’s products) is that smoke alarms are too sensitive when used near a kitchen. You find out that smoke alarms go off far too frequently with even the slightest amount of smoke coming from every day cooking. Customers hate being annoyed by the false alarms. And they hate having to climb up on a chair in order to temporarily turn off the alarm. And you find out that many customers get so frustrated by this that they take the batteries out of the detector permanently, rendering it useless and creating a dangerous situation.

You could communicate to your engineering team how to solve this by writing market requirements that are very specific, such as:

  • Make the kitchen sensor less sensitive than the other ones in the house
  • Or, have the sensor emit only a very brief warning if smoke is starting to build up but not go into full alarm mode
  • Or, have a temporary disable button on the detector

But by doing this you limit the possibilities.

What if you presented the details of this problem and let your team get creative? Maybe they would come back with a smoke detector that has a wireless temporary disable button that could be stuck to the wall next to your stove? That way when a false alarm goes off you could simply press the button and the detector would be disabled for a few minutes until the smoke clears. Or perhaps they could come up with an alarm that is less sensitive only when the stove burners are on for a short period of time, but still sensitive enough to warn if there was the true potential of a dangerous situation?

Don’t limit the brilliance of your engineering teams. Instead tap into it. It’ll lead to better solutions and you’ll find your team coming back to you again and again as you establish yourself as the true voice of the customer.

3 Replies to “Writing Market Requirements Effectively”

  • I disagree. Engineers need to prove that their ideas are solid. Many engineers only look at the problem in front of them and won’t make an attempt to think long them. As a result I’ve had to wrestle with many a products that required massive refactoring because short term, quick solutions were put in place.

    Coming up with the right feature requires strong vision and long term thinking, things in which you need to have a context of the wider market and deep understanding and interest in it, something developers often lack. Having the responsibility to design a feature must be earned by performance and track record and your ability to exceed expectations, not by your role.

  • As a developer who is trying to move to the product management, i cant agree more.Sometimes BA/PMs become almost dictatorial around feature demands stifling our innovative solution.Some of the best and most stable products that I have developed were when a request came from an end-user who just wanted his problem solved and didn’t care how I do it.

  • I totally agree. I learned early on in my product management role that prescriptive requirements come naturally to engineers that have taken on a product manager role. Especially if they come from the project delivery side of things (this is typical for highly complex products or engineered solutions).

    But, providing a good picture of the problem to be solved from the user’s perspective allows engineering teams the freedom to deliver solutions that the product manager may never have envisioned.

    My biggest issue is getting “old school” people in the new product introduction process to get away from the highly prescriptive formats expected in Marketing Requirements Documents. These are often only completed to check a box in the process and the team moves on with effective user stories. Such a waste of time to build “old school” MRDs these days!

What are your thoughts? We’d love to hear from you.

Your email address will not be published. Required fields are marked *