It’s not your job to write requirements

Published 29.09.2020

Author Fabian Peter

Categories Product Management

Tags

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.

Join 100+ cloud native enthusiasts

and stay in the loop on modern software development.

Sign up to receive exclusive content around cloud native software development right into your inbox.

We don’t spam! Read our privacy policy for more info.

More stories from our blog

What’s new in Kubernetes v1.21.2?

What’s new in Kubernetes v1.21.2?

It's June, and Kubernetes has released a new update with version 1.21.2. We will have a look in brief at the changes that came along with this update. We will also have a look at the bugs that Kubernetes removed ahead with the few things added. Let's roll. Changes...

Chaos Engineering: Not so Chaotic

Chaos Engineering: Not so Chaotic

It feels very complex when we talk a lot about cloud computing and developer operations. Furthermore, certain things look complicated, but they are not so if we easily understand those concepts. Today, we will discuss such a thing that sounds complex but is simple and...

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...

Observability: Your Eyes in Cloud

Observability: Your Eyes in Cloud

Observability is all around the cloud. You might come across the term while exploring the vast stretches of documentations or blog posts, maybe videos or streams too. Well, from far you might have seen that this is a very broad term, and it’s expected. The topic is...

Cloud Firewalls Simplified: Beginners  Edition

Cloud Firewalls Simplified: Beginners Edition

Cloud technology is everywhere. From your photos to big corporations carrying out their day to day operations. But have you ever thought about the security needed to protect this vast pile of data? Security from external attacks by threat detection and elimination is...

Object and Block Storage: How They Differ?

Object and Block Storage: How They Differ?

The difference between block and file storage makes heads spin due to the complexity of definitions and technical jargon across the internet. Even a technical person sometimes forgets the business value and makes decision fatigue their best friend when trying to...

Helm: Why DevOps Engineers Love it?

Helm: Why DevOps Engineers Love it?

Kubernetes doesn’t have reproducibility built-in. At least, that’s what we hear most people complain as a cloud native consultation firm serving both startups and enterprises. I have been using Kubernetes for a while now, and it stands up to the mark of being a gold...

Interested in what we do? Looking for help? Wanna talk about software strategy?