It’s not your job to write requirements

by | 29.09.2020 | Product Management

Being a product manager is not about writing requirements. You’re not supposed to descend from Mount Sinai to bring the technical version of the Ten Commandments to your developer followership.

Requirements imply a one-way street.

The PM produces the requirements and the engineer delivers. This is essentially a client/vendor relationship, and it leads to a lot of bad products.

As a Product Manager, it’s not your job to define a solution. You define a problem – and then enable your team to find solutions.

Shipping products is a collaborative and creative exercise that involves product management, design, engineering, user research, data analysis and several other functions. While each person on the product team has a role to play, they are all on the hook for delivering a winning product.

And for that, written requirements — even in the form of user stories — are rarely the best tool for the job.

Effective teams acquire a shared understanding of the problem by talking, drawing on whiteboards, slapping post-it notes on the wall and talking to customers together. Shared understanding doesn’t come from handing off a requirement doc. It’s a dynamic process of discovery and collaboration.

Delivering that winning product is no linear process.

The only requirement for your team is to communicate what they learn with everyone else so that together you can evolve your shared understanding of the problem you’re solving and the product you’re delivering.

Feature factories

Building solutions collaboratively is hard if you’re constantly acting on feature requests from stakeholders (including customers).

As a Product Manager in such an environment you’re not really doing product management at all — and certainly not leading an empowered product team. You are in a feature factory and, as such, your product is being managed by others.

If stakeholders are dictating what features to build, you’ve ceded the process of defining the solution. At that point, all the product team is doing is clarifying and documenting business rules, and controlling for product usability, scalability and technical performance. While this can still be challenging work, it handicaps the true potential of the team.

A product team has to own the full lifecycle of product discovery and delivery. It must validate that the given solution is valuable for the customer and viable for the business. Limiting the team’s mandate to feature-delivery never yields the best results.


The DevOps Awareness Program

Subscribe to the newsletter

Join 100+ cloud native ethusiasts


Join the community Slack

Discuss all things Kubernetes, DevOps and Cloud Native

Related articles6

On Charming Engineering Culture: My Notes

On Charming Engineering Culture: My Notes

Engineering teams are at the core of any modern organisation. They break/make an organisation, and empowering them is critical to any modern companies’ success. A motivated engineer brings more value than a ‘whatever’ engineer. Its high time managers and leaders focus...

Release early, release often

Release early, release often

I guess we've all heard this. Here's a little background to why this might be a real good approach for you - or why not. Linux The Linux Kernel is developed in a bazaar-style approach. Historically, software has been built in a more cathedral-style approach as in...

The Impostor’s Advantage

The Impostor’s Advantage

You certainly heard of Impostor Syndrome - the feeling of accomplished people belittling their own talents and constantly being terrified of being discovered as a fraud. While it might feel like a handicap, it's actually an advantage. You already took the hardest step...