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

Fogg Behavior Model

Have you ever wondered why you do certain things? Why are some behaviors easy and joy to do while other not so? And your customers - have you ever struggled to understand their behavior?
BJ Fogg, from Stanford University, has created simple and powerful behavioral model for persuasive product design.


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.

2017: Less of How, more of What, and a little bit of Why

Focusing less on how (methodologies, frameworks, processes). For me, that was the most important product management trend in 2017. Surely, "Agile" talks are bottomless. Yet, I noticed a certain tiredness and dare I say, boredom among product community with regards to this topic.
- Maybe that's enough? Haven't we discussed that like thousand times? Shouldn't we all have that figured by now?