To leverage the huge unused potential, we need to define the primary role of product managers and their collaboration with development teams quite differently. Product managers should be assigning their teams problems to solve instead of predefined work to get done. We need product managers and team leads to become experts in facilitating inclusive participatory problem-solving in their teams to build innovative products long-term, and to solve the hard problems of their businesses.

In this article, I am going to look closer at the negative and destructive consequences of working with disempowered teams in what has become known as the feature factory organization. I will show how the most innovative product companies of today seem to work very differently, and I’ll talk about two examples from my personal career that have been very eye-opening in that regard. In these two cases, a very similar feature was built but for different software products. One feature idea and implementation originated from the traditional top-down, factory-style approach, and the other from a collaborative product discovery process. The difference in team engagement, and the unfolding development process, was very noticeable.

Building with disempowered teams

So let’s dive into the feature factory example first. In this case, the product manager wanted to create upsell opportunities by displaying resource usage statistics on the user’s dashboard. The hypothesis was:

When people realized they’d often reached the limits of their current plan, it would make them upgrade to a higher plan to get rid of bottlenecks due to exceeding limits.

The disempowered team was assigned predefined work, and was asked to build the more-or-less fully-fleshed-out feature idea in the typical top-down approach. Though the feature idea might make sense at a first glance, unfortunately, it didn’t have the team’s buy-in. This was because the team didn’t believe that this was something that the customer really wanted. After all, they were daily users of the software they built themselves, and did not imagine the feature to be very useful.

Above that, the team’s buy-in started to shrink even further after it became clear to the engineers that the usage data necessary to build the feature was very complex to collect and store in appropriate ways. At this stage of the project, the product manager had become very attached to their own idea and did not really seem to listen, nor address the team’s concerns.

Because of the complex upfront engineering work required, it meant that it took a team of some of the most senior engineers in the company to spend several months to ship a first version of the feature to finally test customer adoption, and the original assumptions of their product manager. The return on investment for this project was a complete disaster. In the end, lots of money had been burned and the team was demoralized.

Building collaboratively with empowered teams

Now let’s look at the second example from my personal career, and a way to build software quite differently. In this case, it was also decided that a usage data widget on the dashboard should be built, with the difference being that the whole product development team came up with the feature idea, not their product manager alone. The team was only given a high-level objective by their product manager, some business context, and hard evidence that the problem really existed and was relevant for the business to solve.

The team was assigned the objective to improve the retention time of the customers by reducing churn during the first days of product usage. A very diverse mix of people from Product, Design, Engineering, User Research, Support, and Analytics spent five days together with a professional facilitator; brainstorming, exploring a wide variety of ideas, discussing, doing rapid prototyping, and even testing their prototypes with real customers on the last day. This process is called a Design Sprint and was invented at Google.

After five days, the group decided to implement the usage statistics widget. They believed that visualizing the user’s learning progress over time within the product, and also displaying it next to the average user’s learning performance, might feel motivating. The bet was that it would make users come back and use the software longer and more often.

Above that, the group regarded the feature as low-hanging fruit in terms of feasibility because part of the team knew that they were already collecting the required data, unlike in the other project. Hence it was already available for consumption and presentation by the frontend via the use of a simple open source library. After only six weeks, the team was able to fully AB test the new feature on production to validate their hypothesis, and to see if it had a positive impact on customer churn. The product manager was then able to decide if it was worth spending further time on the idea.

Huge difference in team engagement

Looking back at those two projects, the huge difference in team engagement and creativity is so eye-opening. But unfortunately, most software products are still being built with the typical top-down approach. And I have worked on a lot of projects like that in my career. In fact, too many! And this has often felt frustrating and demotivating to me and the teams I have been working on. But I have always remembered how different it felt in the more collaborative approach of the Design Sprint.

Building with less risk and an experimentation mindset

So what are the key differences between those two product cultures outlined above? First of all, it should have become clear that building by the second approach carried far less risk. The group’s hypothesis could be tested on production after only six weeks. But what made this possible? Since the whole development team was included in idea and solution discovery very early on, the feasibility risks of the various generated ideas were discussed from the very beginning. Furthermore, the scope of the feature was much more flexible compared to the top-down approach where everything seemed to have been set in stone. In the second example, the team was empowered to make their own decisions and cut corners, if and where necessary, to ship and test within the six-week budget they had been granted.

Unlocking creativity and innovation

But much more important is another key takeaway I got from the more collaborative approach. The solution idea had the whole team’s buy-in because they had been invited by their product manager to discover possible solutions together. For the first time, they felt like they had been treated as adults and domain experts in their workplace.

Everyone was rolling up their sleeves when given a real voice in making a plan together. The whole project had felt similar to how detective work, or how experimentation and discovery in science, must sometimes feel like. It had felt creative, empowering, and engaging; like a much more mature and elevated way of working together as a team. Furthermore, I found it energizing to see how we were able to leverage the group’s full, cross-functional expertise and creativity during the early solution discovery phase. The wide variety of ideas getting discussed and explored during the Design Sprint was impressive.

Generating engineering cultures

I have come to the conclusion that this feeling of empowerment and inclusivity in generative engineering cultures cannot be underestimated in the work context. It is actually one of the key ingredients that make up great product cultures in the most innovative companies today. Job autonomy and understanding the purpose of an undertaking can unlock unseen motivation and people’s full potential. I have often found it frustrating to see how we, as leaders in the software industry, are often wasting this enormous creative potential that lies dormant in our disempowered teams. Why are we paying these enormously high salaries in the tech industry, but then refusing to trust our people and treat them as the very capable domain experts they are? Very often employees know their company, the product, and the codebase inside out. Sometimes they have been working for their company for many years; sometimes much longer than the product managers themselves who are now assigning uninspiring work to them, often without listening to their concerns, ideas, or what they have to say.

Getting from mediocre to great

I have seen what is possible and believe in a more empowering and collaborative way of building software to drive real innovation together. More and more companies are understanding that they have to build and foster very different product cultures to get from mediocre to great. It takes a great deal of courage, and a huge mind shift because it will require you to start trusting your people 100%. But I believe there is no real alternative if you want to run a sustainable business in the long-run, and keep up with more innovative competitors entering the market.