You are not building a product. No, you are not.
You are not building a service. No, that’s not what you do.
So what do you? You are helping another human being to be really great at something! (I’ve touched on the subject before) I’v been planning to write this post for a while, and now I will dig into practical advice on how to maintain true customer centric product development, and how to explore: “purpose”.
This is no revolutionary new idea, but it is really hard to do. In my experience a company has a Product manager or Creative director that is responsible for knowing what kind of features the software developers should be working on, based on customer needs (hopefully). It’s usually the features that is the main topic of discussion at the company meetings – how they should work and what constraints we need to consider (yeah, we do it at Osom too). Nothing wrong with that, except when the features loose touch of purpose.
So how can we make sure all product development is actually making the user kick ass at something?
The Scrum methodology deals with purpose somewhat by stating a user story with a clear business reason. The user story is usually described like “As a X, I want to accomplish Y, with business reason Z”.
Example: As a customer I want to list all my previous orders so I can print them for my accountant. This story is fine and the featured needed is fairly easy to estimate by a dev. The problem here is that it mostly describes activity and not purpose. We need another layer before this that evaluates that this is actually the best way to solve the customers problem.
Introducing: the User Pain Story
The User Pain Story: My accountant hates me because he has to wait for me every month to get a summary of our expenses and I don’t have the time to give it to him.
Suddenly there are lots of ways we can solve this pain story! We could get the accountant access to the previous orders listing or send him an automated monthly email with all the information he needs.
The pain stories are crucial to being a product manager. You don’t need to discuss pain stories in company wide meetings but you need to reflect on them personally or within a small group of product managers. You should gather information by talking to customers, doing user testing and comparing your product with competitors. With this intel you can formalise the vision of the product and develop KPI’s that makes sense to monitor your progress. The pain stories will help you determine the best cure for a customer problem, from a range of options.
Hidden Pains
Note that pains are rarely expressed explicitly by a user. You need to dig deep to find what is bothering them. A root cause analysis can take you pretty far when you talk to a customer.
Watching a user using your product and listening to them is the best way to collect valuable intel.
- The first impression lasts. What does your tool do for a first time user. Can they accomplish the most important task within X minutes without training?
- What’s the users work environment like? Any bosses or clients that depend on the activity performed by the user?
- What is the most important pain killer to a major customer problem and is it intuitive to see why your tool will be the best cure?
- Is there a part of a common work process that takes a significant amount of time?
- Is there a way your product will redefine how users work in their organisation?
The product development process
Most well designed tools come from a developer’s understanding of the user’s pain and she therefore accepts the reason why a feature is proposed by the product manager. By using the Pain story as an example you will get a solid feature foundation and more clear discussions around a feature.
- Find your method of collecting user pains
- Write them down and discuss in a small group
- Come up with 2 or 3 solutions to each pain. Pick one
- Use the pains to plan and validate your feature backlog
- Go build amazing tools that serves a purpose.