Publicerat

Product managers that create that special magic

product-stakeholders
Are you a product manager? Then this has definitely happened to you (and here’s what you can do about it).

Your product team starts developing a new user profile page. Mid development your system architect lets you know that this will impact the data caching and will add more development time. How much? It’s hard to say. The problem is really complex…

Next, your designer has finished the UI design. You both think it looks really good, but the designer added a few more data boxes to the design and you originally talked about. Alright, we’ll have to try and squeeze that in there.

Development continues, but is roughly aborted by the head of PR saying that we just signed a deal with a really important partner. It’s imperative that we rebrand our startpage asap to reflect this. Ok, some people are put aside to work on this.

Then everything breaks. Customer service get bug reports on that the payment process is broken. The CEO does not like the new user profile design. All development gets delayed. Team morale is at the bottom.

Who’s fault is it? Yours.

Being a product manager is about making hard choices, setting a strategy that benefits the entire company and making sure that all stakeholders are happy with this. In the case above (which we all experienced) the product manager failed to analyze and explain the implications of the different changes that came in from the side to the people suggesting them.

As a product manager you need to know the product by heart and still not be the domain expert in all the details. You must not be afraid to ask the question “Or what will happen?”. It’s really easy for a developers to say “We need to fix this or the site will break” or a PR manager to say “this partner is what will allow our business to take off”. As much as you need to trust their judgement, they need to motivate why, and how it will break or at what level it will benefit the company. The same goes with marketing, sales, pr, customer service and design. You need to get the processes in place to get the right information in the right time to make the right decisions.

To get past it’s a lot of work. You need to manage changed customers demands, internal politics, loud and passionate co-workers with huge pride in their individual work and the constant risk of making a bad call.

When all departments in the company are aligned with the product vision, that supports the company goals, and processes are in place to include ALL the stakeholders interests, that’s where the magic happens!

Publicerat

Product managers need the User Pain Story

pain
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.

  1. Find your method of collecting user pains
  2. Write them down and discuss in a small group
  3. Come up with 2 or 3 solutions to each pain. Pick one
  4. Use the pains to plan and validate your feature backlog
  5. Go build amazing tools that serves a purpose.