The Importance of Product Management for Your Startup

07/13/2017 | By Mark Berman

This post originally appeared on

I’ve worked with many startups over the years, and I’m constantly surprised by how few have solid Product Management disciplines.

Why is this important you might ask?

Well, if you’re writing code without a clear understanding of who will be using your offering, how your offering compares to competitors, and how you plan to drive adoption and make money – the reason why you’re in business – then the odds of success dwindle dramatically.

Still not convinced?  If you’re raising money or plan to do so in the future, your product strategy is as important, if not more important than having a good pitch deck, and a well-articulated product strategy is derived from good product management practices.

So what is product management?

Know Your Customer

In her recent Techstars blog post on the Importance of Marketing, Lauren mentions persona development, and this is great step in understanding who your customer is.  This is also a core piece in user centered design, and the foundation for Agile stories.  

Why is this important? Because it forces one to be clear about who’s going to use your product, and how they will benefit from using your product.

Know Your Competitors

One of the most powerful exercises when thinking through a product strategy, is understanding who your competitors are, and how your competitors price their offerings.  You need to understand both their free and paid-for features.

A simple exercise is building a matrix that lists your core features in Column A (row by row), with your competitors in each column from Column B onwards.

You can then easily highlight which feature is addressed by your competitor(s), and which isn’t.  You can also get creative and create one matrix for free, another for paid, etc.

Another use of this is to build a heatmap, where you score your competitor(s) completeness compared to your own feature(s) or offering.

You can also do the same to depict how your offering will change over 6 months, 12 months, etc., mapping out the path to a complete product offering.

Tablestakes vs. Differentiators

The competitive matrix exercise is a great way to get honest with yourself about what it will take to compete.

Knowing where you’re weak today is a good thing, as it helps hone your messaging and positioning for all outbound marketing-related activities.

But more importantly, knowing where you’ll differentiate really helps guide where your focus should be when positioning yourself against your competition.

Feature List

Another great benefit of a competitive matrix is that it helps provide the framework for a feature list.

But often, with new services and offerings, you may not have a 1:1 competitor.

A great exercise is to get all team members into a room, and use post-it notes to write down all the features you think you need for your offering.  You can time box this exercise to 30-60 minutes.  The point is not to have a debate, but rather to write down the exhaustive list.

The next step is to “affinitize” or group the common features into buckets.  These buckets then become pillars for your offering, depending on the level of granularity.

Now, the hard part is prioritizing.  One easy exercise is to allocate a certain number of votes per person.  The idea is to allocate a small number of votes per person to force prioritization.  Stickers could be used to cast a vote on a feature by each team member.

This is usually where some debate happens.  Once again, you can time box this exercise to 30-60 minutes.

At the end of this, which most likely wouldn’t be more than a few hours, you have a detailed feature list, grouping of features, and an internal perspective of prioritization.

And what does the prioritization give you?  A place to start in terms of sequencing work.


Now the really hard part: opening up your feature list to customers to validate your internal prioritization.

It’s surprising how infrequently this happens, and how resistant teams are to doing something like this.  More often I hear the comments: “we know what we’re building”, “why validate? Customers don’t know what they want”, “we don’t have customers,” etc.

But all these excuses are the exact reasons to do this exercise.

The idea is to strike a balance by not providing too much detail, and to frame groups of features as scenarios in ‘customer benefit speak’ à la Scrum Stories.  This is where the art of product management comes into play.

Surveys and 1:1 customer interviews are great ways to capture feedback.  The important thing is to use some structure, like a survey, so that feedback can be tallied and analyzed in a quantitative way.

Ideally, you have already created some buzz about your offering, and have implemented a way to capture early adopter interest – e.g. via a signup form.  This pool of early users is usually surprisingly eager to provide as much feedback as possible.

If you’ve done the exercise right, the odds are your internal prioritization will be adjusted to reflect real customer needs. That’s a great thing, because your roadmap is now aligned with what customers actually want or need.


Notice how there’s been no discussion of writing code yet - that is by design.  

Why?  Because it’s easy to build something when you know what you’re building, and for whom you’re building it.

Once you’ve been able to reconcile the customer feedback, the next step is to prototype your thinking.  The goal as you move through these stages is to avoid writing code as much as possible.

“No code? But how is this possible?” you might be wondering.

Wire framing is a simple but very effective technique to conceptualize functionality from a user interface (UI) perspective.  There are many third party tools that help with this, and some are as simple as using PowerPoint, with add-ins such as PowerMockup, and others are much more sophisticated like

The idea is to provide an interactive prototype, i.e. a user can click on buttons, interact with dropdowns, etc., as though the application was real.

This is where that pool of early adopters come in handy once again, as they’re a great audience with which to share your prototype.  The idea is to give them a task to perform, but without telling them the steps.  

Recording how they use your prototype is critical, as it allows you to capture the user’s frustrations and elations with using your product.  It’s also a helpful tool to use after the session, as it helps to re-watch the recording and share it with other team members.

If you’re really good at this, then one great technique to use is to offer an A/B test scenario, i.e. where you have a user perform a task with prototype A, and then you have them perform the same task with prototype B.

Presenting different ways to solve the same problem is a helpful way of stimulating dialogue both within your team, and especially with customers.

If you don’t have a pool of customers, or would like to expand your pool of customers, existing services such as User Testing are great ways to recruit testers.

Lock a Plan

With a clear prioritization that’s been validated by customers, a prototype that customers have reviewed with feedback incorporated, you’re now in a position to lock a plan.  

That plan can easily evolve into customer centric epics and stories – in Agile speak, can be easily broken down by stage of the product lifecycle per your prioritization.

And as one phase gets completed, the entire process gets repeated over and over again.

Easy isn’t it?