How to say no: Advice for new product people

A friend of mine emailed me on LinkedIn recently saying he’d gotten a new job doing product management at a tech company with an existing online product. Previously the CTO had been managing product but the CEO wanted to bring someone dedicated in. He was asking if I had any pointers. Shotgun solutions are never a good idea without knowing the problem / context however — here are some pointers based on my experience in situations like this.

Get the leadership to agree on what outcomes they’re looking for

Vision, mission, strategy, goals… these are all really important to start with and to keep revisiting. If these artefacts exist for the product you’re managing, dust them off and get everyone around them again. If they don’t ensure you create them before talking about features. Also don’t settle for the first iteration of these statements. For the first draft persevere until you feel in your gut (the gut of your gut) that it’s reflecting the sentiment of the leadership. This step is essential because unless you agree on where you want to go, as a team you will not be able to measure your progress in getting there.

What makes you different?

It doesn’t hurt to do a SWOT on the whole product. Where do you think you have been or can be strong? What opportunities does this yield? What type of a path are you carving in the market? Who are the competitors? How will you answer the question “why should I go with you versus them?” BTW — put the answer on a flag and fly that around. That is going to be your

What are you selling? What are people paying for?

This can be a tough question to answer. What are you really selling? What are people paying for? What is the value that you bring and the problem that you’re solving. If you have existing pricing structures, dust those off and critically review them. Why are they pivoted on XYZ metric? Has it made sense to do this? Are you bundling in features people don’t want or would otherwise pay for? What is the leader feature people must pay for? Do you have a very clear understanding of the cost of goods and cost of customer acquisition so you can model the profitability of the product in different usage scenarios? Don’t be afraid to look dumb by asking questions in this area. It’s the most critical aspect of your product. A great product marketer I know recently said “just imagine buying a BigMac meal at McDonalds and they try bundle in a Croissant — you don’t even want the croissant — it should be separate.”

Who are your customers and what pain point does your product solve?

I’ve rarely seen ideation be a problem for any company I’ve worked with — perhaps it is because I’ve always worked with startups where they’ve carved out an opportunity by innovating so it’s in their DNA. So given this background, the challenge is actually to not get excited about that solution before verifying how big of a problem it is. We were recently in a concepting workshop with a large customer and I started to get excited about a solution our platform could offer regarding shipping pricing across market places. The customer seemed engaged with the idea but not ecstatic. I asked how much of a pain point this was, “90% of our shipping is free anyway.” Boom. As cool as the solution was, it didn’t solve a pain point the customer was having. I’ve written about this before, knowing the problems you’re tackling (and which you arent’) is critical.

Define your product

It amazes me how much of product management comes down to being a good CIO. The ability to manage the “data” that defines what your product does and will do is critical. Essentially, it will help to classify the key capabilities of your product. You can put this list in a heirarchy that has different levels of granularity but it’s the stuff you care about. For example “my platform has the feature access control” and “our access control has the capability to control view and edit rights separately.” Once you list these capabilities out — lock them in with IDs and then start the process of cross referencing everything on the planet with this list. You should aim to have a competitive analysis across your capabilities, all inbound customer opportunities should be mapped to your model of your product’s capabilities, revenue opportunities, market data — all things should conform to your view of the world. Once you have this list it might be best to maintain it in a database like JIRA and then cross reference with other databases you have — hook up some BI if you can. Or failing that — just model in spreadsheets.

A framework to say ‘no’

One of the biggest mistakes any product person can make is barrelling down a road without really knowing why. That question ‘why are we doing this?’ is the core of what you do. The pressure of feature ideas is immense, and without developing this framework that helps everyone understand what we’re doing and why — then all is just subjective and you look like the bad guy. I hope this helps.

If you’re a product person and you have some getting started experience that you’ve found valuable — I’d love to hear about it. Feel free to comment or link to something you’ve written.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.