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:
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.
You give him the title he wants, without a team though. The title will delay the disappointment, but he’ll eventually leave.
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.
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.
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.
Learning how to build up a company with two incredible entrepreneurs (thanks for inviting me on to this journey, Sven & Johann).
Establishing a product culture ‘of my own’ by forming an impactful product management and design team.
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.
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.
30% Click Rate on provided contact recommendations and 50% of recipients become a WAU within 30 days.
The hypothesis template can be accompanied by the following tools. Either prior or past filling it out:
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.
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.
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.
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.
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.