I came across the post Using OKRs to focus on customer problems by Viktoras Jucikas. It is highly interesting and certainly practical, but to my mind it has a close similarity to Impact Mapping and even Management by Objectives. Still, however you may call it, it is a critical tool for product managers.
You may have notice the link from Ellen post that I quoted last week about How to deal with Software Engineers. Hilarious, yet so true…
Product Management is fun. There are some dark sides, however, that you simply need to cope with, as Ellen wrote in her post “The Dark Side of PM:
- Your work doesn’t have the same inherent rewards.
- People don’t understand your work.
- You give more recognition than you get.
If you’re fine with these drawbacks, welcome to Product Management!
Which timeframe should your roadmap have? The post The 666 Roadmap suggest having three different roadmap timeframes: 6 weeks, 6 months and 6 years. Others might call the 6-year roadmap a vision, but why not see the vision as a very high-level roadmap? 6 months is your current plan, the next features, releases, etc. 6 weeks are your current user stories and sprints that you actually work on and have a very deep understanding of.
A nice reference to the basic Scrum vehicles Epic, User Story, Sprint and Version can be found at Atlassian’s article Epics, stories, versions, and sprints. When having to explain them to new agile developers/managers/product guys, this article might be worth a read.
Another usability post: 10 Usability tips. Some are well-known, but still a good compilation.
The contents are good, the page looks not like they followed their tips…
Nielsen Norman Group have an interesting article about the use of sliders, especially for mobile applications. Their conclusion: Use slider when the exact value does not matter. If it does, use other means of input.
Every once in a while, I think about the best way to write user personas. The UX Lady wrote a nice post about how to write such personas and provides a template to do so, but my daily experience tells me that the usual templates contain way too much information. If you collect so much information about your users, that’s a great way to learn about them and segment them, but in order to use them in user stories, they contain more information than necessary. I usually constrain my user personas to the following:
- Short background description
- Technical experience
- Ideal world
This is sufficient to effectively work with them.
The UX Lady summarized the insights from Google and Microsoft regarding multi-screen use. The companies made some findings that could have been found by applying common sense, but some ideas are pretty interesting. It is worth a read if you plan to offer your service on several platforms (and who doesn’t, after all?).
Great idea: When it is impossible to estimate a job/task/feature, just budget it. How much time is it worth? Can be build a minimum viable product in the time? This will allow you to develop the best solution in a given time. However, do not define the timeframe by estimating the size of the task…