People learn a certain behaviour and stick to it. The advantage is that they do not need to consciously remember an action, but can act unconsciously, thus reducing cognitive strain.
Now what happens when a well-known UI is changed? People would need to adapt, but will stick to their learned behaviour at first. Like Little Big Details shows, Chrome moved the search field on new tabs but still allows to enter search terms when users tap on the empty area where the field was before.
It looks like an Easter Egg, but is actually a well-designed UI.
Designing emotion is one of the fine arts of product management. This speech about several traps by Julie Jenson Bennett reminds me a bit of typical usability traps, but with regards to emotion design instead. Very nice thought.
- Mindshare Trap
- Experience Trap
- Output Trap
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.