Four things UX needs to know about product management

This is a highly interesting article, since it does not contain the usual differences between a product manager and a designer. It contains a guide for designers on how to work with product managers (and make their lives easier). The format is the following:

  • What is a product manager, what is his job, how does he/she think?
  • What can I do as a designer to make his job easier?

I nice read from a different perspective.

 

What kind if people are highly successful product managers?

The article What Product VPs At High-Growth Startups Have In Common illustrates what high-profile product managers are like. Interesting to read in case you want to copy some of their behaviour 😉

  1. Senior product leaders at high-growth companies have paid their dues.
  2. Engineering backgrounds are optional.
  3. Product leaders at high-growth startups are pretty darn smart.
  4. These product leaders may be ‘CEO of Product,’ but most have never been a CEO.
  5. Rich Mironov was right – not everybody cares about hiring someone with executive-level product management experience.
  6. And *sigh*, yes – most of these product leaders are men.

Information, Perception, Truth

What you see is NOT what you get!

This is somewhat obvious to most of us, but sometimes software product lead users in a “wrong” way. Users have a hard time reaching their goal. So we need to keep in mind the difference between presented information and perceived information, and that there may be more than one truth.

I would like to refer to the article “Information, Meaning, Perception & Truth

Benefit-driven Metrics

Are you measuring the right metrics of your product? This is a question posed in the essay Benefit-Driven Metrics: Measure the lives you save, not the life preservers you sell. It claims that you should measure the customer benefits instead of internal operating metrics.

I agree to a certain extent. It depends on your business model what you measure. If your users pays you, measure user satisfaction. If you sell the data, user satisfaction is a means to reach your business goals, but not the goal itself.

Killing a Feature

Killing a feature is a hard task for a product manager, because you can be sure that someone will complain, and that you break someone’s workflow.

But in order to build a great, focused product, you need to sunset a feature when it does not fit anymore.

Here is a guide on how to kill features properly:

  1. Confirm the condition is terminal
  2. Stop offering it to new sign-ups
  3. Divide users into two camps
  4. Announce end of life to remaining folks

Reducing choice to increase focus

Decision fatigue is real: People can only make a certain amount of decisions. A good product is not necessarily the one providing most options in order to fulfil every need, but the one reducing complexity in order to make it easy to use.

It is has to build such a product, because there will always be someone complaining, but focus helps your users.

Think in order of magnitudes

This has been a topic for some times: Google wants its employees to think in order of magnitude, not in percentages. They want people to grow the business/product by 10x, not 10%.

The calculations and business model behind this theme are irrelevant to my mind: The concept is all about mental attitude rather than money. People need to think big to build big things. So I have to agree.

Does software estimation make sense?

Richard Clayton wrote an post on why software estimation is useless which has received mixed responses.

He correctly points out the advantages and disadvantages of software estimates. While he concludes that estimation is useless, I conclude that it is useful despite the disadvantages. His only proposal to do better is to work until the budget is spent. (That makes sense when a story is indeed inestimable for some reason).

I believe that his approach may possibly work for paid project, but not for standard software development.