Career Paths in Product Management – Building Products vs. Building People

At one point in time, every PM will arrive at the point at which she has finally gained enough professional experience at her current or past job to climb the corporate ladder. Promotions become a thing.
And thereby it’s not about leveling from which level, but about the act of leveling itself.

While this may seem natural at first sight and was the de facto only way to gain recognition of a good performance, things have changed a bit in the past.
Growth trajectories of people are no longer only focussed on the vertical direction but the horizontal axis.

In the context of product management, this means that you have to choose between continuing to build products yourself compared to instead focus on building people who then build great products.

When you arrive at the point in time mentioned above in time, I strongly advise you to take a moment to check your real inner motivators instead of immediately jumping on having a new business card entitling you as Team Lead Product/VP Product, etc.

This also the very first thing I check with applicants. By focussing on motivators of someone in the first place you can avoid a couple of uncomfortable situations to find yourself in 6 months down the line:

A great product manager joins your small team with already clear leadership ambitions, which you didn’t check in the first place and only discover a couple of months in. One of 3 things will happen:

  1. You’ll have to put him off again and again when he’s asking for a leadership opportunity. His excellence in building products will decrease, and he’ll eventually leave.
  2. You give him the title he wants, without a team though. The title will delay the disappointment, but he’ll eventually leave.
  3. You give him the title and start unplanned hiring to create an artificial team for him. He may be happy, but you created unhealthy growth (and thereby financial burden) for your company and put way too much on the line. Only to satisfy the needs of one employee. On whom you didn’t do your hr homework.


You promote a great product manager to a leadership position who accepts out of politeness but has no leadership ambitions at all and is more than happy in an executive role. Here’s what’ll happen:

  • She’s leading people based on the corporate hr playbook but remains at the same time way too involved in operational details of daily product building because that’s way more interesting (and challenging) for her.
  • Her team grows frustrated and eventually starts to quit.
  • She discovers her true motivation based on building products instead of building people and quits as well.
  • You have to re-hire a product leadership position and the individual contributor roles of that team. Just because you didn’t check the real motivators of your initial hire.

So, whether you’re a product leader hiring for a team or a PM who is approaching a ‘critical’ level of experience: Check your true motivators and whether you’re more driven by building products (and want to continue to deepen your knowledge around that) or building people (with all the trade-offs of being involved continuously of the daily product details.

How Alignment supports you in Stakeholder Management

Why do Stakeholders always come up with Feature Requests? Because they’re like users – They don’t know what they want.
Influencing the roadmap solely with specific feature requests is their way to remain involved in product development continuously.

Why do they want to stay involved? Because they’re not convinced that the end results will match their expectations. You haven’t earned their trust (yet) and they may also have a hard time giving up micro-level control over ‘their’ product.

It’s your responsibility as a Product Manager to reverse engineer their feature requests using alignment tools to get to the bottom to what they want.
Only then you can come up with better solutions than they can imagine.

So, the next time you’re frustrated with the way stakeholders articulate their need, remind yourself to treat them like your users.
Develop empathy for them, get to the bottom of their actual problems and deploy ideation and creative techniques against those problems to come up with better products.

I know, in an ideal world, we’d all be on the same page already. But on the bright side, you can count on an educational effect on your stakeholder’s minds as a byproduct of problem-centered product development.

But be certain that this is your responsibility. The worst you could do would to just built those specific feature requests.

How LinkedIn Premium does Churn Prevention

I looked at the cancellation process of theLinkedIn Premium membership to find out how the professional network tries to prevent its paying members from churning.

You can find the complete transcript of my teardown right below.

  1. Alright. So, I think I’m done with LinkedIn Premium for now. Where could I go to cancel my subscription…?
  2. Maybe up here, right next to my (pretty) face
  3. Ok, that’s fairly obvious and accessible. Let’s take a closer look.
  4. A bit grey to spot at first sight but at least in the right place. Kind of a dark pattern to make it look disabled, though.
  5. Clear and concise comparison of my current (‚Premium Essentials’) and potentially future membership (‚Free‘) status
  6. The ‚Continue‘ button is also even the highlighted one (fairly uncommon for cancelation processes).
  7. Neat idea: Routing me to the FAQ section or offering me a different membership type as additional paths to pursue from here. But let’s continue with the cancelation process.
  8. Rather ‚… – you have to provide feedback‘. The confirmation button is disabled until I’ve selected one of the provided options. I’m wondering whether I get a tailored offer when selecting a reason…
  9. Let’s pick the most obvious reason. Of course it’s too expensive. Every membership is too expensive. Always.
  10. Oh, looks like the last button was already the final one and I get offered a nice discount for coming back. I’m not a friend of those, as they devalue the original membership value.
  11. But, you know what, works on me. I’m a sucker for discounts (and honestly: who isn’t?). Let’s claim the offer. I’m wondering whether I would have gotten it when I had selected a different reason…
  12. Plain confirmation of my successful comeback to the membership and straightforward display of my 50% discount rate right on my account page.
  13. But, in the end, they were not able to keep me around even with the discount. I went through the process one more time and completed the cancelation without being offered any further discounts.
  14. What I like in this ‚canceled‘ state my account is now in are the visible but non-intrusive hints for ‚reactivating‘ (better than resubscribing) my Premium status. Nicely done, LinkedIn!

Productish Podcast Episode 35: How Product Thinking influences Discovery & Delivery Processes – With Nikkel Blaase, Product Designer at XING

In this episode of the Productish podcast, Tim and I are joined by Nikkel Blaase, Product Designer at XING. We’re discussing the impact of Product Thinking on Discovery and Delivery processes in organizations, which prerequisites must be met to implement this mindset and what comes after Product Thinking.

Note: This episode of Productish is in German.

Listen to it on iTunes or SoundCloud and don’t forget to subscribe via RSS or directly on iTunes.

Back to Product

Becoming Director Iridion

When I joined ORBIT mid-2016 I was driven by three goals:

  1. Learning how to build up a company with two incredible entrepreneurs (thanks for inviting me on to this journey, Sven & Johann).
  2. Establishing a product culture ‘of my own’ by forming an impactful product management and design team.
  3. Diversifying my ability to apply product management frameworks in discovery and delivery by working with clients from a broad range of industries.

Now, one year into the consulting business, I had to admit that despite all the various challenges I was able to tackle, nothing drives and motivates me like building for the outcome of ‘my’ product.

That’s why I was so intrigued by the opportunity which resulted from conversations with André and Thorsten: Leading the overall efforts for the conversion management suite Iridion as its Director from October 1st on.

I’ll remain located in Hamburg and can’t wait to further shape and scale this already great SaaS product with our distributed team while leveraging a close connection to the Web Arts HQ in Bad Homburg.

So, when you personally or the company you work for/with are centered around (conversion) optimization, let’s talk about how Iridion might fit into your workflow. Reach out to me via e-mail, and we’ll set up a call or meeting.

MerkenMerken

Lean UX Hypothesis Template for Product Managers

Lean UX Hypothesis Template

While stating the critical hypotheses around your product are already part of the early product discovery phases, it’s sometimes difficult to find the right format for executing against them. I ran into this situation just recently and decided to put together a straightforward hypothesis template which I want to share with you as a free resource.

How to use the Hypothesis Template

The hypothesis itself should be stated following the structure of what you want to build for whom and to achieve what kind of impact. A simple example would be:

We believe building a prominent “add contact” opportunity in the news stream for freshly registered users will achieve an increase of 10% WAU within this segment.

Afterwards, you have to define which qualitative or quantiataive experiments will help you to validate this hypothesis. Ideally, you can come up with an experiment which doesn’t involve your development team (hint: I’m talking about similar challenges at the 2017 Product Management Festival in Zurich).
For our example from above, one experiment could be sending out contact recommendation e-mails even earlier than originally planned to check whether the action of triggering more contact adds support our hypothesis.

Afterwards, we have to set a time constraint for our experiment(s) to run and define the target outcome at which we would consider the hypothesis to be validated.
Like:

30% Click Rate on provided contact recommendations and 50% of recipients become a WAU within 30 days.

Complementary Tools

The hypothesis template can be accompanied by the following tools. Either prior or past filling it out:

Besides the free download as a scalable .pdf, you can also grab the hypothesis template from my GDrive and duplicate it into your own account for modification purposes.

I’m curious to hear how the template works out for you. Let me know on Twitter or via E-mail!

Productish Podcast Episode 34: The relevance of Technical Excellence in Product Development

In this episode of the Productish podcast, Tim and I are discussing the importance and relevance of technical excellence in product development. Besides discussing the actual definition of the term, we also touched on specific tools and best & worst practices.

Note: This episode of Productish is in German.

Listen to it on iTunes or SoundCloud and don’t forget to subscribe via RSS or directly on iTunes.

How XING accels at Product Management

My friend, former colleague and Product Tank Hamburg partner in crime Marc Kadish recently gave a talk at the Working Product conference in Hamburg.
He shared some of the key principles and framework XING uses to define its product roadmap and level up its product management game.

It’s the best (public) summary I’ve seen so far on the topic of operational product management at XING and this is why I want to share those valuable insights from my former employer with you.
You can get the whole talk and his slides from the Working Products website but here are the key aspects of it.

All slides and images courtesy of Marc Kadish.

Impact Mapping

Product Management at XING - Impact Mapping

Quarterly Roadmap Rhythm

Product Management at XING - Quarterly Roadmap Rhythm

Design Thinking

Product Management at XING - Design SprintsRead my take on what it takes to fuck up a Design Sprint and what specific mistakes you should avoid as a Product Manager.


Data Informed Decision making

Product Management at XING - Data InformedRead my advice on how to avoid 5 common A/B split testing mistakes and which essentials you shouldn’t miss as a Product Manager.

Autonomy Through Alignment

Product Management at XING - AlignmentHere are my favorite tools for alignment including the Auftragsklärung framework used at XING.

How to calculate your User Churn Rate

Calculating user churn rates is essential if you want to maintain a continuous growth strategy. Whether it’s for the primary stakeholders, upper management of external investors: Knowing your churn rate is essential especially when you’re running a SaaS product when your revenue ties directly to the quantity of your user base.

Simply put, churn is customers you’ve lost in a specific period of time. Tracking this metric forces you to re-evaluate your product strategy (and possibly do a reset). If churn is high, something about your product is turning away users. The churn itself is of course expressed in obvious numbers from your BI team – But it’s the relative metric user churn rate which

Churn itself is of course expressed in obvious numbers from your BI team – But it’s the relative metric user churn rate which lets you compare your churn rate against forecast and competitors.

This is why I’ve created a calculation sheet which I want to share with you. It focusses on the acquisition/user base side of churn. It provides the calculation base for 12 months and exposes your monthly and overall churn rates.

As always, if you have any suggestions for modifications in the sheet, either send me an email or leave a comment in the file itself.

Sometime over the coming weeks, I’ll also create a sheet specifically for calculating payer churn – Useful when managing a freemium product. While it’s then more about your payer base instead of the overall user base, thinking in cohorts is also beneficial when e.g. evaluating upsell mechanisms within your product or upsell focused marketing campaigns.

Product Managers need to be micro Pessimists but macro Optimists

I recently heard about this attitude in a podcast interview with Raylene Yung, reporting that it reflects overall company values at Stripe.
But instead of ‘only’ applying it on a business level, I think it’s also quite a suitable framework for the split of perspectives product managers face on a regular basis.

It’s kind of an analogy to the discovery and delivery separation every product manager needs to handle. While the one (delivery) focusses on execution in regards to ongoing sprint routines, details of backlog items and hitting milestones on time, the other one (discovery) focusses on customer problems worth solving and what to build next.

From my experience, optimism is key for going into a product discovery. That doesn’t necessarily mean to be overly enthusiastic about a certain feature.
Furthermore, you should be looking forward to the digging into customer or business problems and the creative journey that you’ll identify something valuable you can build up on with your team.


On the execution side, I found the ‘right’ degree of pessimism helpful for staying on track. That doesn’t mean that you should doubt the success of your team on a regular basis, but challenging (your own) priorities and decisions at least during every sprint planning.
Don’t take yesterday’s decisions for granted – As long as corrections still fit into the overall product vision.
Remain skeptic that the path you chose for the next sprint will still be the right one when looking back at it into the retrospective. This way, you’ll stay hungry for ongoing improvement and avoid an ‘now we just need it build it’ attitude.

Your macro perspective should always be mostly positive. This will give you the confidence to question decisions on a micro level more regularly without becoming scared that you’re losing touch with the big picture.