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.
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 😉
- Senior product leaders at high-growth companies have paid their dues.
- Engineering backgrounds are optional.
- Product leaders at high-growth startups are pretty darn smart.
- These product leaders may be ‘CEO of Product,’ but most have never been a CEO.
- Rich Mironov was right – not everybody cares about hiring someone with executive-level product management experience.
- And *sigh*, yes – most of these product leaders are men.
I read Atlassian’s article on permissions for sprints. They introduce a sprint permission scheme so that not everybody can manage a sprint in Jira.
This may certainly help , but I never made the experience that permissions were misused and anyone changed a sprint inappropriately. So is this really necessary? I am not sure.
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
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.
Decision making is one of a product manager’s core activity. Read this wonderful list and decision-making techniques to be prepared for every scenario there might be.
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:
- Confirm the condition is terminal
- Stop offering it to new sign-ups
- Divide users into two camps
- Announce end of life to remaining folks
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.
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.
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.