The Four Things All Product Managers Are Trying to Figure Out

What you do as a product manager is different at every organization, with every product and with every product team.  There is no one “right way” to do this job.  You have to be able to adapt and adjust based on the unique dynamics of your situation.  With that said, what you are trying to do and the value you are providing is always the same.    Regardless of the size of the company you work for, the maturity of your market or the type of product you are building, I’ve found there are only really four things we are all trying to figure out.

Do More with Limited Resources: 

No matter what size company you work in, there is never enough time, money or engineers to get everything done you want.img_0018
It’s easy to understand you have constrained resources when you’re working at a startup.  Everyone is well aware of the amount of funding you have, how many deals that are in the sales pipeline and thus the runway you have.  In those cases, your job is to make sure that there is no waste in your product plan, because every decision feels like it could make or break the company.  Your reward for doing that well is that you get more customers, the company gets bigger and the list of stuff to do only gets longer.

It’s kind of like your own personal budgeting.  When you were in college, you were able to pay for food, tuition, clothes, housing and beer on a shoestring budget.  As you progressed through life, your paycheck probably got bigger as did your budget.  Instead of rent, you have a mortgage.  Instead of tuition, you have kids (and then your kids’ tuition), and so on and so on.  And in my case, the beer budget shifted from quantity to quality.    The point is, while you’re making different choices with a different set of variables, you are still trying to figure out how to make your dollar stretch as far as it can.

Prioritize, prioritize, prioritize:

The number one responsibility to our organizations is to make sure that we are leveraging those limited resources in the most effective way possible.img_0020
I’ll talk about this in more detail in another post, but being responsible for driving priority is not the same as being the “prioritizer”.  (this is the fatal flow in the “CEO of the Product” trope).   Regardless of the size of company, there are plenty of people that take part in prioritization.   The key difference for the product manager, is how many people are involved and how many options do they have.In a small company, it’s probably the leadership team (CEO, head of tech, head of sales and head of product) and you are usually trying to prioritize the business version of Maslow’s Hierarchy of Needs – do we do something for a current customer, do we do something for a prospect or do we do something that keeps the technology from falling over?

As the company gets bigger, there are more opinions and more options which  can make the decisions feel more nuanced and perhaps less immediate.   You probably don’t feel like you are trying to choose between survival options, but that doesn’t mean those decisions aren’t critical.  Deciding to eat healthy vs. hitting the drive-through every day will have very real effects on your short and long- term health.  The same thing holds true on product decisions, which means there is an even greater need for someone to drive the prioritization conversation.

Tell the difference between what is being asked for and what is needed:

So how do you get to that list of things to prioritize?  Some folks in your company will probably tell you it’s not that hard.

  • “Here’s a list of features that Prospect X said they would give us a million dollars for.”
  • “Here’s the top five bugs we get customer calls about.”
  • “Competitor Y just announced the Widgetanor 5000”


Sometimes those are perfectly good answers to what we need to build next.  More often, they are simply symptoms of a larger market need.  Our job as product people is to be able to take all of those things in – along with lots of other market signals – decompose them into actual needs and then recompose them into something the company can build, sell and support.  The bigger the opportunity, the more complex the problem and the less obvious the solution.

Help people through change:

Once you’ve identified the real problems and the right solutions to prioritize, you also need to be able to rally everyone around the product plan.

In smaller organizations, the product manager sets the product vision, works with the engineering teams to build the product, develops the go to market messaging and positioning, and is the sales engineer during the sales cycles.  As the organization size grows, the product manager is still responsible for those tasks getting done, but now enables others across the org.  There might be “product owners” working directly with the scrum teams, “product marketers” developing the messaging and an army of sales engineers in hundreds of sales calls.

It falls on product management to ensure that everyone in the company not only has the information they need, but also have a deep appreciation for what problem is being solved and the value to our customers.   If you don’t invest enough time in helping people through change, you’ll find that no matter how well you do the rest of your job, you will be frustrated by the progress you make.

Regardless of whether or not you are employee number 5 at a cool startup building the next great iPhone app or you are the product owner for an internal tool at a Fortune 50 company, take solace that you are not alone.  Strip away the noise surrounding whatever is keeping you up at night and figure out which of these four things you’re trying to accomplish.  Once you do that, I guarantee it will be a lot easier to know what to do next.

Beyond Tech Debt

If you’ve spent more than 5 minutes with an engineering team, you’ve probably heard about “Tech Debt”.  This is the cost of making a choice that isn’t the best from an engineering perspective, but may be necessary due to market or external forces.

Contrary to popular belief, tech debt isn’t always a bad thing.  It’s kind of like using your credit card – it’s a handy option as long as you pay it off each month.  Unfortunately, it often turns into a big problem because the team never goes back and does it right.  Just like a credit card, this debt accumulates “interest” and if not addressed soon enough, it can bring a product to its knees.  The good news is that most product orgs are conscious of this risk and include it in their product planning and prioritization.

The bad news is that this isn’t the only kind of debt you can incur with a product.  How many times have you been going over your roadmap or release plan and said things like:

We don’t have time to implement Feature X in this release.”
“If we don’t add all of the design, it might not be as ‘usable’, but it will be functional.”

While you may not be incurring Tech debt, you are still incurring some form of debt.  You are making a tradeoff that is compromising what your discovery efforts have told you.  With my teams, we call this “Feature Debt” and “Usability Debt” and we talk about it just like we do with “Tech Debt”.

Most people seem to get Feature Debt.  It’s pretty straight forward

  • We identified a feature
  • We wrote stories
  • We did designs
  • We scoped the effort
  • We DIDN’T release it

Usually Feature Debt is handled in the backlog and since the product manager championed this idea and is managing the priorities, it usually gets addressed somewhere.  (As much as I hate to admit it, product managers often don’t give Tech Debt the same sort of love.)

Usability Debt is a little trickier because the question of “What is usable?” can be fuzzier and often times it’s not consistent from one part of the experience to another.  Do you really need to have the same level of usability for a feature that is used once a year, by one person as you do for something used hundreds of times a session by every user?  Probably not, but it can be a slippery slope.  We break things out in three levels:

  1. Functional: This means that the interface can trigger the server to do the task that’s intended.  You know you’re in that land when you hear phrases like “It’s not pretty, but it works!
  2. Usable: This is where it is not only functional, but it makes sense to the user and it helps them accomplish the task in a way that makes their experience positive.
  3. Delightful: Now, you’re in product/UX nirvana.  You are surprising the customer and they not only have a positive experience, they “LOVE” the feature or product.

While I agree, we should all be shooting for delightful, the reality is that it’s not always realistic due to other market/company constraints.  With that said, we should never just accept functional, because while it may save time, it always ends up hurting your product in the long run.

To help us manage both the different debt types and to ensure that we have a clear understanding of what are the acceptable levels of debt, my teams have instituted something called “Debt Floors“.


debt floors.png

Instead of thinking of them as how much debt are we willing to accept and calling them “Debt Ceilings”, we want to instead think of them as limits on how much we are willing to sacrifice to still meet our objectives.

This allows us to establish a set of standards for technology, features, and usability that will ensure that we produce scalable, reliable software that makes it easy for our customers to do their jobs and evoke feelings of delight and joy.  By defining these “Debt Floors” we can create a set of criteria to ensure we don’t compromise our definition of quality.