When Product Teams ask what to build, they no longer are Product Teams

When teams start new projects, more often than not, they are either delivered a set of requisites, or they ask the stakeholder what to build.

Either way, Product Teams — if they think of themselves as such — stop being Product Teams immediately in that moment.

In that point in time, they become Delivery teams. Delivery Teams that possibly don’t fully understand the problem and lack context of what’s being built. Delivery Teams that are only focused in delivering what was asked and not in the desired results. Delivery Teams that aren’t empowered to take advantage of their knowledge and creativity when new challenges appear.

The Right Product Mindset

At Whitesmith we have been, throughout the years, constantly fostering a Product mindset in our teams: we try to fully understand what we are building, we’re not afraid to make questions, and we do suggest different approaches in case we believe there are better ones.

This was a big step on top of what most Delivery Teams are.

But it wasn’t until recently that we noticed we were still doing something wrong in that front — a question that we made even before the other ones came:

“What do you want us to build?“

That was, explicitly or not, what we asked our clients when they first came to us.

After that, we did make good questions and suggestions — we didn’t simply accept everything that was asked to execute.

We did care, we were praised for being a good team, and we did deliver fantastic features with a great approach. But this is where we capped: we built great features, but not great products. Because we cannot be great at building products if we don’t fully understand and question the problem we are solving.

We built great features, but not great products.

Today is different. Today we first ask what the problem is, and validate it, by extracting the most knowledge possible from our clients, by researching about the industry, interviewing customers/potential customers, and so on.

It’s only then that, the Product Team, along other stakeholders, can define the best approaches for the problem at hand. These are the approaches which are then translated into the product’s definition and its roadmap.

Only then the team can use their knowledge about the problem and industry, their technical expertise and creativity, to define what should be built.

If you enjoyed the read, please click the clap button to show your appreciation!