A few years ago, I was a Product Manager at a growing ecommerce company. Our platform helped celebrities sell products they endorsed to customers. A huge part of our team was spending a lot of time on the phone answering the celebrities’ questions about running their store. We knew this wasteful process wasn’t sustainable.

When we started developing our Product Roadmap for the next year, management decided to build a seller portal that would allow the celebrities to be self sufficient in running their stores.

At the beginning of the project, we interviewed a few of our celebrities for testing. We asked them what they wanted in this portal and included their requests in the product specifications. After three months of development work with a team of seven people, we launched our final product. Everyone, including our CEO, were incredibly happy. We congratulated each other on the job done. We even threw a party to celebrate the product launch.

After the launch, I was constantly checking analytics to see how many celebrity sellers were using our new product. To my dismay, I found that even after onboarding them personally, only three out of one hundred sellers were using the portal. Phone calls kept rolling in ever since.

What happened? We had talked to users. We put everything they could possibly want in the product. We were using Scrum. Where did we go wrong?

I contacted the sellers to find out why they did not use the portal. All of them said it was easier to just call us rather than use the portal. We had added all the features they had asked for, but it was too dense. They were not tech savvy and our user experience was too complicated. They just didn’t want it.

I started to realize we had focused so much on the act of building this portal that we didn’t stop to consider if what we were building was the right thing.

This concentration on building instead of thinking is what leads companies into what I call “The Build Trap”. When we are just starting out, we have to constantly test our ideas with the market in order to find something that sticks. As we find product/market fit, the company starts to grow but the commitments to investors and stakeholders do as well. Now the pressure is on performance.

We start planning more products to expand and become larger companies. Product Managers are constantly adding ideas and requests from customers and management to the Product Roadmap. When the time comes to build that particular feature, we plan the sprints and the designs based on the ideas that we originally had. We’ll add a week or two for writing specifications and customer research before development Sprints. We’ll then build the product and launch it to customers.

This is the path that leads us into trouble. Our first ideas are often not our best ideas. They’re subject to personal and environmental bias. The seller portal was a tool our management team would like to use, but our sellers were not interested. The heads of our business were biased in their own thinking and their own ways of utilizing  technology. They neglected the fact that the people who we had built our portal for were very different.

Another problem is that users’ often need change between the time an item is added to our Roadmap and the beginning of development. The small amount of time set aside for user research isn’t enough. Agile by nature is about rapid feedback, and yet when we run Sprints we often don’t release it to our customers until the whole product is built.

After the disaster with the seller portal, I looked for ways to make sure we were building what customers not only needed, but also wanted. For the next project, my team tried the Think > Make > Check cycle. First, we brainstormed customer problems and thought of ways to solve the biggest one. Then we focused on building in small batch sizes,  constantly testing in front of customers. Within three weeks, we found a new feature for our company that increased sales by 33 percent.

As I work with other product management teams to get them out of The Build Trap, I’ve found there is a huge cultural problem that prevents companies from being successful. It comes down to the reward system and incentives for the employees. Companies don’t reward teams for thinking; they reward them for building. Developers are praised when they pull all-nighters writing thousands of lines of code and getting it in for a deadline.

In performance reviews, managers look at the amount of work people have done, yet rarely review the metrics that affected work. Companies constantly focus on the outputs of  their people and not the outcomes they produce for their customers and business. This is a very flawed system because the amount of features a team produces is no guarantee of a successful company.

Getting out of the Build Trap is not hard, but it’s a journey. Start with these three steps:
1. Kill your bad ideas quickly so you can focus on the good ones.
Teams who test with customers early and often during product development know for a fact what customers will respond to and can act on it before proceeding. Adopt the Think > Make > Check cycle for every product you build or improve. Create a panel of customers who can give you honest feedback. Launch small products so the panel can try them  out before you invest in building the whole thing.

2. Concentrate on problems in Product Roadmaps, not features
Instead of putting the first ideas for products on the Roadmap, put down the problem you want to solve until you have time to test and find the best solution. I’ve used this  approach with my clients and call them “Problem Roadmaps”. For example, we could have said we wanted to “Reduce the time we spend on the phone with sellers by 50 percent in Q1.” Then we could have evaluated all the possibilities on how to solve this problem, selected the best solution, and spent our time building it. Focusing on the problem instead of our original solution would have saved us 3,360 manhours and thousands of dollars.

3. Reward outcomes over outputs
In standups, instead of saying “What have you delivered today?” start asking, “What have you learned today, and how will it help us?” Reward people for thinking projects through and saying “no” if they prove a feature idea is not worth building. Have a party when you achieve your goal, not when you launch your product. This will inspire employees to find a solution that works, not race to launch a product that customers won’t use. We spend a lot of money learning how to build software right, but we often don’t make sure we’re building the right software. At the end of the day, we have to remember that building is the easy part of the product development process. Figuring out what to build is the hard part.