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
When you have a new product management job, what are your tasks in your first couple of weeks? Study the product, architecture, speak to developer, sales and support, have a look at the roadmap…
The guys at HipChat add a task that they consider even more important: Speak to users. They say: ”
Your job as a PM is to find the right problems – then work with your team to solve them.” So to understand the problems, speaking to users is a better way than studying the product’s architecture.
So you have a great idea of a new product or feature. Anyway, how will you know that anyone else will like it and, more importantly, also use it?
Inspired by Marc Andreessen’s tweets, Hutch Carpenter asks three questions to evaluate the possible adoption of a product:
- Does the idea target an actual job-to-be-done that enough people have?
- Is the idea a meaningful improvement over the current way people fulfill their job-to-be-done?
- Does the value of the idea to customers exceed the cost of the idea to them?
You can also rate the answers and display them in a kind of dashboard, but that’s all eye candy.
Have a look at this feature: Yelp for iOS — When in New York City, the two tightest distance filters are measured in blocks, not miles. Isn’t this neat? I guess every user who uses Yelp in New York City appreciates this feature. It shows that Yelp is a user-friendly application that cares about the users’ needs.
I wonder, however, about the feasibility of developing such a feature. Yelp is a world-wide service, and only a minimal fraction of users actually live in New York or visit the city. The feature, despite being small, needed to be thought of, described, assessed, developed, tested, rolled out… this is a lot of effort and cost. Is it really worth implementing a neat feature for a very small user group? I think not. What is your opinion?
Product Management can be a tough job. With the goal/Feature/function/product in mind, a very long way has to be gone at times. This makes us proud. However, the user of the product probably does not care at all. Pete Warden pointed out Things users don’t care about:
- How long you spent on it.
- How hard it was to implement.
- How clean your architecture is.
- How extensible it is.
- How well it runs on your machine.
- How great it will be once all their friends are on it.
- How amazing the next version will be.
- Whose fault the problems are.
- What you think they should be interested in.
- What you expected.
- What you were promised.
- How important this is to you.
So we all need to stop boasting or bickering and focus on what users do care about.
An interesting way of deriving features from actual business goals is Impact Mapping. The centre of the process is the business goal, which several groups of people contribute to. Each of the groups can contribute in certain ways, and therefore needs specific features. This four-step approach cannot replace any planning, wireframing, etc., but if the goal is fixed, it helps you see which features are needed by which people.
There has been some discussion on whether the Who or the How should be the second step, and the author decided for the Who. Of course, anyone using this technique is free to adapt the concept.
Predict human behaviour! Users do not alway act rational. They type and speak unprecise and still complain when the software does exactly what they asked for.
Good software predicts the intentions of the user and asks for confirmation, should there be room for misunderstanding. Apple’s Siri is a good example, as shown by Little Big Details. Around midnight, it is unclear what “Tomorrow” means, so Siri asks the user for confirmation.