In my professional life I‘ve been an entrepreneur, a software engineer and a consultant. For the last three years I took a deep dive into product management working as a scrum product owner at XING. Now — with quite some learnings — I am heading back to my own business.
I’d like to share my top personal insights I will take with me.
1. Build for outcome
— Never start a project without clear constraints
If somebody is approaching you with an idea or a request, ask:
- What is the difference in the world after this project?
- Why do your users need it?
- What will be the change in life of your customers?
- What exactly is proof for that change, in numbers?
- When do your customers need it?
Only if you get answers, continue. Otherwise you might build something nobody wants.
2. Build around people problems
— And develop customer-centered KPIs
Product managers are facing two kinds of challenges: (1) deliver on a user need or (2) reach an internal requirement. The 1st one is a problem for people, the 2nd mostly is a problem for the company. Whose problem are you trying to solve in your current project? What is your KPI?
I really want to make a case for seeing everything in product management from the customer’s perspective.
Users have problems and needs in the first place — even before the product and company exist. They need change. They struggle in a situation. And they try to solve it using your solutions.
When applying the jobs to be done framework we learn it’s the user offering a job in the market and companies are allowed to apply for that job. If you are successful users hire your product to make progress. If you do it wrong your competitor will get the job. It is not the company anymore offering a service to a user.
This perspective changes everything, also what we set up as measurements for our products.
Model your KPIs around how users measure success and not around business goals.
Only the customer knows if a product helps in making progress or reach a specific goal. And they measure the hired solution against an expected outcome. That means there might exist an working KPI system for your product out there already. Why then translate a working mental model into a business-centric view the user does not understand? She simply will not care for your company goals. And while we think we are doing great because KPIs are great this might not be the truth for the customer. That’s why we need to think in user-centered KPIs.
There is another good reason for thinking this way: The customer job does not change over time but the solution does. If the metric covers making progress with the job a company may change the product but measurements are allowed to stay. This will be key to long-term value creation.
3. Love the problem space
— and fear the solution space
If I had one hour to chop down a tree, I’d spend 50 minutes sharpening my axe.
Sharpen your axe and move deep into the UX space to really understand your customers before thinking in solutions.
Get out of the building. Really. You have to talk to people. I know it’s damn-hard but do it from the very beginning and as often as possible. Do not even think the word “feature” as long as you can. While others are debating about data, opinions, correlations inside a meeting room … you got already out on the streets testing your ideas with humans.
Build lo-fi (paper) prototypes for faster learning. Write scripts for your interviews. Try to come up with a falsifiable hypothesis before talking to users. Interviews are also experiments. Be naive. Be open. Ask people about their situations, struggles, goals, expectations, pains, gains, habits, fears, desires … finally:
Uncover the job and the solution becomes obvious.
Once you got the job you will finally understand the customer. Then features become easy — and this is also true for marketing messages, copy, SEO, landing page design, conversion funnels, you name it. This post by Nikkel Blaase also covers the core question: What do people really want? When answered we can start building for a meaningful change in the life of our customers.
4. Build for Learning
— ship experiments not features
When thinking about a product change for your users I basically have no idea if I am right. I have no clue what will happen after shipping. »You never know before you go« is a simple truth, but not an easy one.
The only way to find out if sth works is simple: ship it.
Treat everything — every idea, user feedback, what stakeholders say or what research found out — as an assumption you want prove. The only way to do this is to invalidate or validate via experiments. The knowing is in the doing.
The tenth principle of the agile manifesto says: “Simplicity — the art of maximizing the amount of work not done — is essential.” They already got it back in 2001 — today we call it lean startup. The most important thing is to prevent waste and to learn and adapt fast, doing small steps.
For getting into this kind of thinking I found it very helpful to reverse the build-measure-learn loop: Start with learn and then go backwards:
- What do I want to learn?
- How can I measure this?
- What is the smallest thing I have to build for measuring?
This helps to build for learning instead of thinking in solutions. To ship an experiment we need two more things: (1) a date and (2) a falsifiable hypothesis. This gives us measurable expectations we can experiment against.
Example:
- Learn: Will people value my content over time (aka retention)?
- Measure: Opening rate of email
- Build: Weekly email with valuable content
Experiment: Sending weekly mails to 1000 users will generate a stable opening rate of > 50% over 4 weeks.
It really gets interesting when the timebox passes. What happens if I fail? What if not? Then true learning can happen and I will plan the next experiment based on the results. Then I go back to the three questions above.
As said an experiment may also be an interview. Then one could write a script and build a hypothesis around the answers of the prospects: e.g. “5 out of 6 people will give a clear positive response regarding my idea during 1 week of interviews.” Learn-measure-build depends on what kind of signal can invalidate your assumption.
5. Draw pictures
— Have more fun at work and be saved from boring meetings
Britta Ullrich showed me how to draw nice pictures with minimalistic efforts. It is really fun if you let go of shame.
Drawing is a great way for communicating to the team or to stakeholders — and it can save you from some boring meetings.
Fill your walls and people will stop by to talk about things. If you are invited to a meeting just bring your drawings — no need for powerpoint. Even better: just have spontaneous and informal conversations right in front of your wall. You can stay in your problem space which will lead to more fun, insights and ideas.
Your artifacts may last a while. And you only have to create them once. The roadmap picture I drew went some time with me. At a glance it explains past, present and future of the product and the next meaningful steps. I even took it to the CEO to explain the overall plan.
6. Product Innovation over Optimization
— It’s hard but possible to innovate from the inside
I believe there are — at least — two ways of product discoveries:
1. Improve against the competition
The customer already hires a product (aka the competition) for a known job to be done.
Challenge: Try to initiate a switch because there are big problems with the current solution. Or only parts of the job are done and we can do much better.
2. Innovate
The customer does not consciously know about a job and there is no solution in the market to hire.
Challenge: Uncover the job and come up with a first solution. This is about inventing a new offering versus re-inventing a value proposition.
I would always go for the 2nd one, but there are issues:
A real innovation is always not wanted by no one in the 1st place. If you’d ask your boss for budget for an innovative idea, he has to say: “Why should I invest in such bullshit? My boss will kill me.” This is the nature of innovation and also the main problem.
»There will never be a mass market for motor cars — about 1,000 in Europe — because that is the limit on the number of chauffeurs available!« — Spokesman for Daimler Benz
Cars driven by normal people — unbelievable at those times. Every innovation must be seen as crazy in the beginning. The risk of losing money is very high. There has to be great trust. You must be allowed to fail and to lose all the money. It may take long time. Usually there is no place in the system for such an approach that’s why it is so hard to innovate from the inside.
Nonetheless we innovated during a product discovery in 2015 @ XING and I am very grateful that this was possible. It was bottom up, it took its time, there were objections and fears sometimes on the way. But in the end we uncovered a job to be done for a major user segment which today’s product is not hireable for. If hypotheses come true when scaling later this year there will be a big long-term value for both, the customer and the company.
7. Know your personality
— and the people around you
In the team we played around with Myers Briggs Type Indicator which was really fun. Each of us was trying to find out her or his personality type. Sharing this in the team helped me to find my place and to understand a lot of past experiences. In the MBTI I am an ENFP (the campaigner). Here you can do the test yourself.
Another great way of getting more into your own personality is the strength test by the University of Pennsylvania (login required, but it’s free).
The results of MBTI and strengths deeply resonate with me and helped me to understand some situations from the last years. For me it would be a good idea to be the generalist in a cross-functional and autonomous team generating ideas & impulses, seeing the whole picture, being creative and intuitive and pushing the others to start or to ship. There should be at least one other N-type in the team. Somehow this enables building on each other’s ideas.
Conclusion
The last years my thinking became really outcome oriented. Assumptions should be treated as what they are: unproven hypothesis about the future. Solutions do come late in the product thinking process. Last things last.
I also will incorporate lean and a deep customer orientation into my future work. Embracing the users’s perspective and use an experiment-based development approach will lead to long-term value and prevention of waste.
Getting closer to my own personality together with others was a great experience and I definitely want to recommend those tests.
For digital product management as a discipline I believe customer jobs thinking combined with user-centered metrics will become the de-facto standard for the development process in the near future. So stay tuned!
Jan is an Entrepreneur and Product Guy living with his family in Hamburg, Germany. As a Consultant he helps companies with Lean Product Management and SEO. He is looking forward to connect!
