This is the follow up to the post “What makes young product teams suffer”. Here’s a TL:DR of the 7 scenarios mentioned in that post:

1. Weak communication between engineering, product and design teams
2. Projects, tasks, code and dependencies are disconnected
3. Teams care about dependencies too late
4. No thinking, planning and mapping before execution
5. Different processes even within small teams
6. [Design/Product/Frontend]-Driven Scoping
7. Scope-rigid and timeline-rigid

Before acting: make the issues clear to everyone

Leaders tend to jump straight into solution-mode, but driving cultural change requires everyone’s buy-in, otherwise it’s just another top-down policy. Show the issues the team is suffering from, give space for reflection and drive them to…

After leading some product teams over the last years, I’ve found 7 issues present in the majority (if not all) of them. These problems were identified in multiple stages and models, from early stage to growth stage, VC-funded to bootstrapped, B2C to B2B. The “younger” these teams are (i.e. junior PMs or recently established groups) the more these problems cripple their day-to-day. In a follow-up post I will tell you what I’ve done with my teams to tackle these issues.

1. Weak communication between engineering, product and design teams

These teams likely started separately, maybe outsourced or highly siloed (to “protect their focus” 🤦), but the greatest blocker to…

Cultural debt and “assholism” are the deadliest poisons existing in companies. Both are invisible. For this post I am going to focus on the first.

The objective of my short essay is not to provide an antidote as there’s no quick recipe for this. As it is cultural, it is unique to each company. The objective of this writing is to bring awareness. Make it less invisible, make it more addressable.

But first…

Let me briefly demonstrate the base of my analogy: technical debt.

As per adaptation of wikipedia, technical debt “reflects the implied cost of additional rework caused by choosing an…

There’s a lot of amazing content out there about how product managers should work with those around them. From how we should engage with developers to dealing with designers, as far to how we manage everyone’s expectations ¯\_(ツ)_/¯. To be fair I do have some personal favourites such as Julie Zhuo’s posts; they’ve been quite helpful shaping my own way of working with product designers (in particular with this and this). But, in my honest opinion, there’s not enough written on how others should work alongside a product team (and making our lives a bit better). …

A few weeks ago I was having a discussion on the topic “building product teams”. The conversation focused on answering 7 key questions:

1. How does your (product) team look like?
2. What’s different in product teams vs. other teams?
3. What is your biggest challenge as a product leader?
4. Should the product manager be the team leader?
5. What do you look for in engineers or designers looking to become PMs?
6. How do you measure success of a product team? Is it product success?
7. What are the “hard things about hard things” in PM — what’s not sexy, but is crucial, in leading…

You know about Bear Grills’ famous meme right?

Independently of your role in your startup, a significant part of your job is being problem manager, often outside your “scope”. Actually, the more soft-skilled/people-related is your position, the more weird “why am I dealing with this?” type of problems you’re faced with.

After a significant number of years dealing with this, I found I go through a sort of “3-stage mourning” ritual that matches the lines of Grills’ meme (though in a reverse order).

Overcome…

Oh the anger part. “As if I didn’t have enough crap to deal with”, “here come’s some…

For the last few months I’ve had an amazing opportunity to advise startups, young PMs and new founders on how to deal with common product-related problems. Part of the role is sharing stuff we tried and tested, and especially exercises we ran across different teams that actually had a a material impact on our ability to grow. Here are 2 of them that can (and should)be ran at any moment in a company’s life.

The quarterly fire-drill

Unfortunately, PMs view product management more around building than managing. But the “little” managing that is done, is generally centred around planning. And planning, in this scenario, focuses more in “forecasting” than “designing”.

Forecasting. The socially accepted word for futurology (read this with John Oliver’s voice). PMs spend a ridiculous amount of time reading the tea leaves. How much time is this going to take? How many story points do you estimate? When would we have the v1? How much revenue is this going to add? And then you add to the roadmap slide deck. And you feel happy. …