Skip to main content

PMs, be proud about stuff you haven't built

Lately, going through fellow PMs profiles, I noticed that we almost exclusively talk about stuff we've built and practically never about things that we avoided building.

That seems logical until you remember that saying "no" is one of the primary PM's responsibilities. Therefore, a good PM should have said "no" to the abundance of ideas, features, and products.

Why not list some of those on your CV? A refusal to build a wrong product might be critical to a company's success. It saves money, helps with staying focused and enables other opportunities.

PMs praised for selling ideas and not enough commended for killing bad ideas. We are rewarded for timely delivery and questioned for "wasted" time we spent discovering the right product.

The uncomfortable truth about product discovery is that in essence, it's finding multiple ways things don't work. It is failing. It is wasting time. However, it's a vital activity to come up with the right product. Moreover, if we would not accept the costs of discovery - the consequences might be catastrophic for a product or an entire business.

Still refusing to build something remains to be one of the toughest PM's activities. It's unpopular. It's questionable.
Our companies pay a lot of money to people for building stuff. And when someone says something should not be built - it inevitably faces scepticism.

I remember the first time I faced the challenge to convince my superiors that something should not be built. We've been sitting in a large meeting room, more than twelve people. Product managers, designers, management. We were looking at the pitch of a potential new product. It was delivered by an agency that already built a product for us. The product was successful, and now they came again with the new idea. That one will be much bolder, ambitious, expensive. It looked so cool on the slides. Those guys knew how to make a good show.

After the presentation and the agency leaving we've had an internal debrief. Everyone was still pretty pumped by what we've seen. We started talking about go to market strategy, marketing activities and the integration with our other products. The overall vibe was extremely positive, and no one questioned the basics. Luckily our meeting couldn't last much longer and we had to conclude it. The decision to build that thing was anything but taken.

I was tasked with ironing the details with the agency. On the plane back home I was replaying their presentation in my head, noting down questions I might have for them. Surprisingly, most of my questions towards their idea were basic. Who will be the primary users of this product? What is the key value it should provide? What are the alternative solutions users might be already using? What are our competitors doing about this problem?

Next day in the office I've been doing some research. The coolness of the agency presentation faded but not the key concerns I now had for their idea. Couple hours of digging brought the revelation. A competitor's product, which had all the features I've seen in the agency's presentation. It was almost 1-to-1 copy. But it wasn't the main problem. The key finding was that this competitor's product failed. Failed miserably. The usage has been low to non-existent and the user feedback was horrendous. Suddenly, all the coolness from the presentation vanished and I couldn't believe how it ever sounded like a good idea.

Now though I had a new challenge. Convince my peers and management that the idea was bad and we shouldn't do it. You might think it would have been an easy job. Just show them the competitor's product and its pitiful state. No, unfortunately, that was not enough. Few key stakeholders were already invested in the idea. They already put their name behind it, imagining the success in the future.
- Competitors? - they'd say, - we're better than them, we'll make that right.
It took numerous long weeks and tons of PM work to prove the idea was flawed and we shouldn't commit to it. In the end, we succeeded, potentially saving the company thousands of dollars and probable harm to the brand.

I never thought about putting this achievement on my CV or telling about it in job interviews. But now I've reconsidered. And so should you. Building stuff is fun, it's cool, and we love doing it. But not building stuff is sometimes as if not more important. It's PM's job to know when to build and when not to. 

Popular posts from this blog

Product management and operations tools - Jira Product Discovery review

  JPD is a new player in the market of product management software. Jira (and the whole Atlassian suite) has been one of the most popular tool stacks for teams to deliver software products. Now they're adding a missing piece - product discovery.

Product Vision: an elevator pitch for your product

On this blog, I write a lot about making data-driven decisions . But what if you just starting to think about your product? You have a vague idea and nothing more. No point to go for prototyping or even talking to customers as you don't know yet who to talk to and what to talk about. In such situation - start from creating a product vision.

2 simple but powerful filters for your problem and product ideas

Nowadays lots of people and companies want to innovate. They want to generate new ideas and turn them into profitable products. But how would you separate good ideas from not so good ones? How would you make sure you invest only in good ideas?