This is part 3 of a 3 part series breaking down the PM Career Framework. If you missed part 1 or 2 check them out here.

Vision and Strategy

Deciding and aligning on what we should do AND what we should NOT do

Leadership

It’s all about developing, keeping, and leveraging trust

Impact

Get Shit Done

Once we have established the strategic direction to work towards and we have a healthy and inspired org to work with, the final piece of the impact puzzle is to execute.  As a PM we will not be solely responsible for delivering on promises ourselves, but there are ways to make a difference on how effectively a team and collaboration partners deliver on goals and get shit done.

Structure

Minimal Viable Process

Put simply, our team will need to take a coherent action from our strategy, and break it down into manageable chunks of work that build towards achieving the goal of that action.  Then they need to take those chunks of work and get them done.  The process our team(s) work with needs to satisfy these two conditions: 

1. It solves for our team’s execution needs

2. It solves for our need, as the accountable PM, for reasonable predictability.

There are lots of options and a wide variety of needs here.  A senior team with individuals who are good at structuring their work might mostly self-manage.  A newer team may require a stricter process.  Regardless, our team(s) should feel ownership of their process, and we should ensure to give them what they need within that process to empower them.  Then keep a dialogue open with the team and help them solve for our predictability needs with the process too.  Retros can serve this purpose, but there are other ways too.

Are we set up for Success?

The process might indicate that our team(s) risk not being able to deliver on the expectations of them.  This can show up in several ways, such as if ambitions seem unrealistic, or delivery suffers from significant unpredictability.  There are many ways to set our team up for success which our Engineering Manager partner will generally be responsible for.  Where we as the PM can really contribute is articulating the impact these issues have in terms of the ambitions and expectations on the teams.  This is needed input to the Engineering Manager and our leadership structure, who will need to weigh various options to help (or choose not to).  Here are a couple of examples of where a team is not set up for success:

• A team has a high load of customer support which consumes the time of two engineers full time, that will greatly reduce the baseline of execution time that a team has.  If the team is thin as a result, it is not set up for success.  

• The tech a team maintains is in bad shape, and as a result they are vulnerable to stop-the-line incidents a couple times a quarter.  This makes delivery predictability challenging, and the team is not set up for success.  

• There could also be challenges with respect to seniority, coverage of different disciplines of engineering, retention, etc.

When our team(s) are not set up for success, we and our Engineering Manager partner must escalate this and help leadership understand the impact of these challenges so they can make a call on how to address them, or explicitly accept the consequences of not doing so.

Org Rhythm

Lastly, in a large company like Spotify, teams are generally part of a larger initiative to deliver on higher level goals.  We don’t need to follow or copy exactly the process that Project Management for that higher level goal has, but we need to arrange our processes so they fit together.  As a leader of a team and department, we are responsible for abiding by these higher level processes, and therefore must be able to get the input from the team at the right time to do so. 

Team Delivery

Empowered Accountability

As part of scaling ourselves we should strive to not be needed consistently in the teams day-to-day.  Instead, we can empower engineers so they understand how a particular chunk of work fits into the big picture and WHY it matters. Then the engineers should be able to make decisions themselves.  With trust established, we can expect the engineers to raise issues if things are not going according to plan.  And as soon as we know it’s not, we can make a call on how to address that.  Of course this does not come for free, and we may need to spend time in the team’s day-to-day to achieve this, but it should be seen as a means to an end.  We can also help this by making themself available for 1:1 meetings with the goal of inspiring and empowering engineers in the team.

Goals and Focus

I commonly hear that Engineers feel they are not productive enough if they have not spent the bulk of their time writing code and delivering things.  But the team is evaluated on if it delivers on the RIGHT things, the things which have the most impact.  Where I personally find I can be most impactful in the day-to-day within a team is by helping them choose a goal to be laser focused on, and consequently protecting them from everything else.  I’d much rather my team swarm/pair on achieving an explicit goal than picking up a new ticket from the backlog. This may unintentionally open up a new workstream which may cause delay on the critical path.  Too many workstreams implies less focus on the goals on the critical path.  The second order consequences are less collaboration, less knowledge sharing, and divergence of understanding and expertise within the team.  This is especially challenging in a remote setting, as pair programming or working together on tasks is less natural.

Lastly, in my opinion the four worst words a PM can hear are “That is basically done”.  This could mean that it just needs to be deployed, needs documentation, needs user verification, or something else which is necessary to achieve the explicit goal of a task.  Set goals explicitly, and help the team recognise that “basically done” is not Done, because probably the impact hasn’t been achieved yet and focus will suffer as a result.

Adoption

The impact a Platform Product brings to the company comes from solving a common problem for the users and teams that depend on it.  This means that when we have delivered a product we haven’t achieved impact until teams are using it AND verify that we have indeed solved this common problem (for them).  So achieving adoption is the final piece of delivery.  We can empower others to do this and delegate, or they can do it themselves.  But as the PM, we can leverage stakeholder relationships to find reasonable options for adoption and set the team up in the right conversations, if needed.

Collaborative Impact

Often the problems we are trying to solve are bigger than one reasonably sized team can tackle.  Therefore, we need to facilitate collaboration across teams in order to achieve impact.

Empowered Collaboration

When facilitating collaboration across teams to deliver on a greater goal, in my opinion it does NOT work to throw requirements in the form of “asks” at teams and hope for explicit commitment.  This sort of collaboration is ripe for misunderstanding and leaving deliveries in the dreaded “basically done” state. It also has limited options to mitigate if the answer is “NO”.  I believe this approach is only effective when we ask another team to do something small, like upgrade a library.  If we need significant collaboration between teams, we need teams to put their own respective priorities aside and buy into the impact that this greater goal will have.  Then the teams learn, work, and iterate together to make it happen.  The key is to set a shared goal between the teams, and keep eyes on the prize to achieve it.  If the shared goal is not achieved, both teams fail.  It doesn’t matter who didn’t finish their part.  Help each other, and have collaborative impact.

Do the Right Things

The flip side of this is that sometimes another PM or team will approach us and try to influence us to contribute to some greater objective that they are trying to achieve.  If the objective the other team is pitching is more impactful than the goals that we have in mind for our team, then the right thing to do is to set our team up to collaborate on this other objective.  

We are not necessarily evaluated on the impact we have within our own problem space. We will be evaluated on the impact we have, period.  The more trusted we are, the more likely it is that we are put in the most impactful problem spaces.  Contributing to these greater goals builds that trust when it is the most important thing we can contribute to.  We just can’t forget to be transparent about the tradeoffs this implies by neglecting or down-prioritising our own problem space.

Predictability

The more collaboration is needed to solve a problem, the more difficult it is to be predictable.  A Project Manager will manage this by being explicit about expectations and asking for commitment, but solving engineering problems is always unpredictable, so this is hard.  The trick is to break things down and try to be as reliable as possible with short term commitments, and always being transparent as early as possible about possible risk to the timeline.  My strategy here is to be “realistic” in the short term (1 quarter) and optimistic in the long term 2-4 quarters.  But “being optimistic” in the long term doesn’t mean “wishful thinking”.  It means clearly presenting the best case scenario, both in terms of outcome and the team set up required for this to be possible.  Then, the second half of that optimism is about being clear about the consequences of NOT setting the teams up for success would have, so that leadership can evaluate the tradeoffs that might be included in that setup.

All aspects I’ve dissected here from the PM career framework are leading towards helping a PM maximise the impact that they have on behalf of their organisation.   We need to learn and discover what the right problems or opportunities are that should be solved.  We need to inspire and lead an organisation that is well set up to solve them, and then leverage the trust in our organisation to get shit done and have impact.  In my opinion, the TL;DR of navigating the PM career framework is to have impact and then recognition will follow.  The career development framework is just that, a framework.  It is intended to help us develop different skills in our roles in order to to maximise their impact.  But those skills are a means to an end.  A means to being an impactful PM.

New to PM? Check out this post with some learnings from the early days, or this Podcast episode about building and marketing internal products for impact.

This is part 2 of a 3 part series breaking down the PM Career Framework. If you missed part 1, check it out here.

Vision and Strategy

Deciding and aligning on what we should do AND what we should NOT do

Leadership

It’s all about developing, keeping, and leveraging trust

As a PM we are not directly responsible for the health of the org, but a healthy org will help us achieve the impact that we are accountable for.  When our direct team is healthy we are well set up for delivery. When the org is healthy we are well set up for collaboration to achieve goals which are bigger than what one reasonable sized team can accomplish.  As a result, Product Management is a leadership position, and leadership is one of the pillars of the Product Career framework.

Org Leadership

A healthy org requires relationships to be established between members both within and across teams in our department or “Product Area” (PA).  It also requires PA members to be challenged, motivated, and generally enjoying their job. By being in a leadership position we contribute to the culture of our team and organisation, which is a contributing factor to the impact we are able to have.

Psychological Safety

Members of an organisation need to feel safe to express their ideas, learn, challenge others, and broadly to be themselves.  This is the foundation of a teams’ hierarchy of needs.  Trust, collaboration, retention and more will struggle until a baseline of psychological safety is achieved.  By being in a leadership position our behaviour is contagious and we contribute to this in a positive or negative way.

Belonging and Inclusion

A healthy organisation requires that members feel like they belong in the organisation, and that the organisation is inclusive to them personally.  There are various approaches a team might take with the explicit goal of achieving this sense of belonging, such as organising all-hands, fikas (Swedish coffee breaks), after-works, team lunches/dinners, gaming sessions and off-sites.  These can be especially necessary in a distributed environment, which also makes it more challenging to be inclusive to various work styles and activity preferences. While not something a PM is accountable for directly, as a leader we do contribute to it and it helps to lead by example.  If we have fun in the team and make an effort to make sure that others have fun too, that will be contagious.  By helping create a sense of belonging in the organisation, being inclusive, and making work fun it will help retention, and enable the development of relationships and trust.

Mentoring and Growth

In order for an org to be healthy, members of the org need to have the prospect of growing in their career by learning and conquering exciting challenges.  Growth of individuals improves the impact an org can have, both by improving and channelling their expertise, but also by significantly improving retention.  This can be done by mentoring junior PMs, helping with the onboarding process of new joiners.  But it doesn’t need to be limited to PMs only.  It is common for engineers, designers or insights people to be interested or have ambitions of transitioning into product.  And even if they are not interested in transitioning, we very likely have developed some transferable skills and can still help them grow in their own roles in other ways.

Feedback and Recognition

We should provide constructive feedback and recognise individuals and teams when a job is well done.  Insightful, constructive feedback helps develop psychological safety, and provide team members with the opportunity to reflect and grow.  Recognition provides reinforcement, motivation and inspires self-confidence in team members.

Scaling Ourselves

I often feel that as a PM I am responsible for everything and nothing.  We are accountable for impact, which requires delivery.  Our Engineering Manager partner is accountable for delivery.  The engineering team builds the things and completes tickets.  Then we often have to collaborate with other teams and their EMs.  We partner with tech, insights or design experts to learn and put together strategy.  And occasionally there is a need for team building events, workshops, all-hands presentations, and more.  It’s a lot, and we cannot and should not do it on our own.

Empowerment

We cannot be responsible for all the decisions that are taken within a problem space.  While we may be accountable for those decisions, it doesn’t scale, and if we are not careful we inevitably become a bottleneck that affects delivery negatively.   Instead we have to empower those we work with to make decisions that we are willing to stand behind.  And for this to happen, they will need to understand not just WHAT to do, but WHY they are doing it.  If we share only WHAT we need to do, nuance is lost, and we create a situation which is vulnerable to misunderstanding.  With WHY, if some aspect of a task is unclear or doesn’t make sense they are armed with the information they need to make an informed decision to resolve that unclarity.

Delegating with Trust

There are not enough hours in the day/week/month for us to complete all the expectations that are on us.  But that doesn’t mean we can drop these expectations, nor should we work 60 hour weeks to get it all done.  Instead we can scale ourselves by delegating responsibility.  This is easier said than done!  We are still accountable for the expectations which we delegate, which means if some expectation gets dropped in the delegation we have done a bad job.  We must delegate with trust.  If delegating without trust, we end up checking in regularly, which implies that we have not released the mental load of the expectation, and have not scaled ourselves.  By spending time on relationships with the partners we collaborate with, we develop rapport and the trust necessary to delegate.  And then we can let go and focus on something else.

Proactively deciding where NOT to engage

Lastly, not all expectations are equally important.  Some might not even be valid.  The third aspect to scaling ourselves is choosing what of those expectations we are OK with dropping or delaying.  In a leadership position we have so much responsibility and so much to do.  If we aren’t careful we will be reactive and do whatever got our attention most recently, which could be a noisy customer or teammate.  If we are working reactively, we are not being deliberate with our time and energy and there is a good chance we are not focusing on the right things.  By spending some time reflecting on what is important and the current state, we can decide what expectations we really must spend energy on, what we can delegate, and most importantly what we can drop or delay.  Doing less things is an obvious, but critical way to scale ourselves.

Transparency

In order for us to scale ourselves we have to develop trust in the collaboration partners around us.  But in order for those in our leadership structure to do the same, they have to develop that trust in us too.  As a result, transparency goes a long way to being an effective leader.

Establishing Trust in Ourselves

All of the points above related to scaling ourselves require operating with a high degree of transparency.  Of course there are some areas which are sensitive and must be kept quiet, but generally oversharing is better than undersharing.  By oversharing we are inviting those around us into our thought process, which helps empowerment, establishing trust in ourselves, and makes clear our expectations.  This is especially important in a distributed and asynchronous work environment.  I believe in sharing early and often, because receiving feedback on a finished idea is far less productive than receiving feedback throughout the process which could cause that idea to change course.

Communicating Upwards

Leading our org is half of the responsibility.  The other half is representing and being accountable for the org to our leadership structure.  By understanding the motivations and concerns of our upper level leadership, as well as WHY, we can be more effective in how we communicate and represent our teams and initiatives.  This means surfacing the right deliveries and updates, not ALL the deliveries and updates.  It also means speaking on a level that will resonate with our leaders, which will differ depending on the person and context.

Don’t be afraid to Escalate

Lastly, our management is accountable for our success too.  If you or your team is not set up for success in our expectations we need to escalate that and give them the opportunity to help.  They may understand our concerns and be fine with the situation, which is a very important message.  Or they may hear our concerns, decide it is unacceptable, and do everything in their power to help.  The earlier we surface when we recognise we are not set up for success, the more likely it is that help is possible, and the more trustworthy we will be as a result.

Impact

Get Shit Done

New to PM? Check out this post with some learnings from the early days, or this Podcast episode about scaling yourself.

In the coming three posts, I have taken the three pillars of a Product Career Framework, broken them down and mapped out my interpretation for how I apply them for Platform Product Management.  Together, a PM I work with and I can then use this breakdown to discuss development areas and set goals.  Depending on the context, certain parts of this framework and breakdown may be more relevant than others at a given time.  When there is overlap between a PMs interest, ambitions, and business need, we should set an explicit goal together.

Vision and Strategy

Deciding and aligning on what we should do AND what we should NOT do

Learning

Quite often we are responsible for driving impact in a nebulous problem space.  There are various approaches which can be used to find clarity in the nebula.  When we need to learn, a PM should understand enough of the current state to choose what they believe is the right tool for the learning necessary.  For example:

Learn about the Tech

We are building technical platform products, which means in order for us to be successful we must understand the tech we are suggesting to build.  Armed with this understanding, we can partner with engineering and suggest solutions that are both feasible and present a viable solution to the problem at hand.  Then this understanding helps us empower our engineering teams to build it.  We aren’t expected to get to the same level of understanding as the tech experts we partner with, but the more we understand the more we can contribute.

Learn about the Users

Platform products have users which are just like consumer facing products, but with key differences and benefits.  It’s easy to operate as though we have a captive audience since we are providing the platform that users SHOULD use to solve their problem, but if we misunderstand the user’s motivations, goals, and jobs they will find other solutions and ignore our product.  We can use quantitative and/or qualitative insights to better understand our users and try to solve for their needs in a way which is a win-win for our goals as a platform, and their own motivations.

Learn about the Strategic Context

Another tool to better understand the problem space is to focus on why it matters to our company.  How does this problem space fit into the big picture? What business objectives is it connected to and how? The context which surrounds a problem is a very important tool to use for influencing others to collaborate with us when solving a problem, and also specifically to understand if we should be instead solving a different problem.

Learn about trends and competitors in the industry

The problems we have may feel very company specific, but when we take a step back and understand the business needs we solve for it is obvious that they are common across most large consumer tech companies.  Platform products are unique in the sense that generally the aspects which make them successful are not secret, and are generally a source of branding for engineering excellence.  There are public blog posts, conference talks which we can find form our peer companies and use for inspiration, and we can also set up knowledge sharing sessions to get into more details.  Competitor trends in this case is not referring to business competitors, but instead other alternatives that others in the industry use to solve the same problems as us, like for example Kafka and Pub/Sub.

This list of approaches is definitely not exhaustive, and depending on the experience of the PM it may not be easy to determine when to use each approach.  We should also be mindful of when we have learned enough.  The more ambiguity in a problem space the more time we need to spend learning.  It is also from experience that we determine when it is time to pivot from learning to strategising and doing.

Forming an Opinion

Armed with a thorough understanding of the problem space, it’s time to form an opinion on how to approach it.

Vision

The Product Vision paints the picture of the perfect world when we have completely solved the problem space.  Having a vision for the problem space is a critical communication and alignment tool for the squad(s), users and stakeholders.  It also places much needed constraints on the set of viable solutions which the team should consider.  And while this is a product vision for us as a Platform PMs, if it is to be impactful it will also represent a critical component of the company's technical strategy for the technical domain.  The Product Vision for a platform product will be tech.  It must be done in partnership with the domain experts for that tech at our company or it won’t get the traction needed to be impactful.

Strategy

Once the grand vision is in place, we need to be opinionated on how to do it.  Good Strategy should present three things:

• A Diagnosis of the problem space, which we formed in the learning phase

• Guiding Principles which we want to follow, which are constraints we abide by en route to the vision

• A set of Coherent Actions that represent the “next steps” we believe we should take.  

With the ambiguity in a problem space, there are likely a variety of approaches we could take, each with their own tradeoffs.  That is why this way forward is an opinion as opposed to a provable “best” approach most of the time.  It is also built on a mix of facts and assumptions, so it is unlikely that we map out each and every of the steps needed towards eventually achieving the vision.

Instead we map out only the steps that will be required to learn more, and then reassess what comes next.  Because of these assumptions, it is important to strive for iterative impact.  We will be learning and validating our assumptions as we go, which implies we might realise we were wrong and decide to change course.  If the strategy only is impactful at the end and is based on wrong assumptions, we will face either a huge sunk cost, or risk moving towards a vision which is no longer a good idea.  With iterative impact, we can easily pivot based on our learnings while still having achieved something useful.

Lastly, an incredibly important and often overlooked part of strategy is being opinionated on what NOT to do and why.  We can only do so much, and if we try to move on all the possible approaches to solving the problem it is likely we fail on all of them.  Strategy must be opinionated on the approach which we believe we should take, and provide the focus to our squad(s) to empower them to do it well and quickly.

Influencing

Once we have a strategy, we need to use it to align our team, our users, our stakeholders and our management structure around the approach that we will be taking and why.

Write it Down

This might sound obvious, but driving strategy with conversations, verbal presentations, and shared context will likely not succeed.  Since the strategy has built in assumptions and opinions, it is very likely that those we need to align the strategy with may have different assumptions and disagree with our opinions.  This implies that strategy is ripe for misinterpretation.  By producing a shareable artefact of the strategy, it makes explicit the assumptions and tradeoffs considered in the opinion.  And by making these explicit it invites conversation from counter arguments and those who made different assumptions.  This is valuable for eliminating misunderstanding, achieving alignment AND triggering the conversations which could spark other creative solutions that are worth exploring.

Speak to the right Audience

The artefacts of our strategy are alignment tools.  We are seeking to align across several levels of individuals, from the most technical engineers on the team, to VPs who will only understand the high level aspects and won’t give it more than 10 minutes of thought.  We need to be concise where necessary, and detailed where necessary.  This probably means that we require multiple different approaches and artefacts to achieve this alignment, depending on the need.  These artefacts also unlock the ability for asynchronous collaboration, which is especially important in a team which is distributed across time zones.

For example, for a single strategy I may have the following artefacts:

• Main Strategy Document

• Executive Summary

• Detailed Diagnosis

• Roadmap

• Slide Deck

• Presentation I am ready to give

• Video (Recorded Presentation)

This might sound like overkill, but lots of them link together, like for example the slide deck, presentation and video.  The trick is to make sure they also produce sharable artefacts.

Repeat it Over and Over (and over) again

People will engage with our communication differently.  Some will understand right away, others will take some time to get onboard to our thinking, others will ignore it completely.  In order to effectively achieve alignment around our strategy, we may need to unapologetically repeat it more often that feels reasonable.

All three of these aspects of the Strategy pillar are collaborative.  It is not expected for any individual to do everything for each step.  In some cases they should be done in a partnership with tech or insights, in some cases we should form allies and delegate in our org or other parts of the organisation in order to scale ourselves.  But as the Product Manager we will be evaluated on the result, so we need to ensure that it happens.  These aspects of scaling ourselves and developing trust I will touch on in the next section about leadership.

Leadership

It’s all about developing, keeping, and leveraging trust

Impact

Get Shit Done

New to PM? Check out this post with some learnings from the early days, or this Podcast episode about strategy and roadmaps

For every decision there is a universe of possible things we could choose to do, some of which makes any sense to do, and something that would objectively be the best thing to do. Being the PM is a lot about navigating this universe, narrowing down the choices, and being able to tell a convincing story about why we chose the path we did - especially if we want people to go along with us.

We already know that you learn new things with every product change, and the path to success is iteration, not a flawless first attempt. We want to invest just enough time in learning, to consistently make reasonable choices. We don’t want to get lost in the hunt for the white whale - the objectively best choice. Unless you’re incredibly lucky, a series of reasonable steps are going to take you further than one perfect first step.

The way we tackle this problem is to learn about the universe we’re in. In our case as PMs: the market we operate in, the problem we’re solving, the users we’re solving for, and the state of our product as it already is.

To be able to learn though, we need information. We need data. Getting this data, and going from having data to learning from the data is a rabbit hole that can be incredibly time consuming and often have steeply diminishing returns. So how do we avoid the rabbit hole? How do we know when to stop digging, learn what we can, and make a decision with what we know?

Fundamentally Data plays two roles in a product cycle. You use it at the beginning to identify opportunities and you use it at the end to evaluate if you managed to capture the opportunity.

Usually the data supporting the two cases is roughly the same. In the opportunity analysis you look at it in an ad hoc way, you turn it around, dig deep, look from many angles to learn the little intricacies. In the evaluation stage you want to remove all such creativity. When evaluating you just want to validate your hypothesis, the hypothesis that you stated as you started changing the product. 

This hypothesis should already have had a metric defined and a rough estimate of how much it should change. If it turns out that your hypothesis didn’t materialize then that’s a learning you bring into the next opportunity analysis. Resist the urge to shift the goal post in evaluation and picking another metric or evaluation criteria - if it didn’t work it didn’t work, you want to learn the right thing for the next opportunity analysis.

So you need data to generate opportunities and hypotheses, and for evaluation. But what data do you need? Big surprise: it depends. More than anything it depends on the maturity of your product. If you’re setting out to leverage your first opportunity or if you’ve been tuning your offering for years.

In the very beginning of the product journey - the opportunities are obvious, and the expected impact of every change is high. You're building the foundation of your product, and if your hypothesis is correct, that should greatly impact your top level metrics. For example: This is where you allow your primary segment access to your value proposition, where you add basic functionality, where you remove the most obvious points of friction.

I like to think about a sequence of opportunities as a tree, where every captured opportunity opens up a new set of opportunities. In each node in this tree, you need the information necessary to form a hypothesis on what change to the product would capture the opportunity. Each opportunity has its own universe of choices and its own set of reasonable approaches. Once you’ve informed yourself about the universes that you have available to you you can evaluate which of your opportunity capturing options is most bang for the buck, and that’s your next step.

As you work through your opportunity tree over time, you rarely close doors behind you. In each node you just chose what to do next, not necessarily what opportunities to abandon forever. So as you progress over time, the set of available opportunities grows. They include the new ones you unlock, and all of the ones you didn’t prioritise earlier. This of course requires that you have more and more data to evaluate which opportunity to go for next.

The flip side of this though is that at the top of the tree, when you make your first choices, you have a limited set of available opportunities, and you can make a choice with way less data. The further up you are in the tree, the more important it is to not get caught up in the data rabbit hole - the opportunity cost is massive. 

Knowing that depending on the set of available opportunities we need more or less data, but which kind of data do we need? It all depends on what metric your hypothesis intends to move.

Higher level metrics require massive impact to change enough for you to notice. Your first opportunities will exhaust the changes that can easily be evaluated with high level metrics and you’ll have to rely on more local metrics to see large enough metric changes to evaluate your hypotheses.

1. In the beginning you’re likely operating on very high level metrics: number of users, revenue, logins etc.

2. As you go further down the tree you’ll have exhausted the changes you can make that individually, meaningfully, move these top level metrics. Now you need to focus on a more specific metric, something like engagement per user, usage of specific features of your product etc.

3. Even further down you’re probably iterating on specific variations of your features or personalised functionality. Now you’d need hyperlocal metrics that capture specifically the variation you made, like the click-through-rate of personalised pieces of content depending on position or some recommendation model state.

To be able to form a hypothesis to move any of these metrics you need to capture that data in the first place. As the metrics grows more local and you chase lower magnitude metric shifts, the more advanced your methods need to be to collect, process and analyse. 

Be honest about which opportunities are actually in reach from where you stand - and which are for you to tackle in the future. Then gather the data necessary to make an informed choice between the actually available opportunities. Choose the opportunity where your hypothesis predicts the greatest impact with the lowest effort. And then make sure that as you ship new things, you also capture the data you need to evaluate the change and be even better informed in the next round.

Don’t compromise with making informed choices, but don’t waste time chasing the perfect decision. Find and leverage the data you need, no more no less.

If you want to hear us talk this through with more examples and tangents you should check out this episode of the Product Internals podcast!

Setting expectations is hard, living up to them is harder.  We try to straddle the line between overpromising and underpromising, with only an educated guess at where the line really lies.  Estimating how much time and work building a new product will take with any degree of accuracy is near impossible, even with the engineers' involvement.  For both Product Managers and Engineers, our ambitions are always bigger than our execution capacity.  So we make our educated guesses and do our best.

Things will go wrong!  There are so many unknowns.  The complexities which a product needs to overcome are always trickier than we and our engineers will anticipate.  Tech debt always affects productivity more than we realise.  There are always distractions, incidents, external asks, and a plethora of other reasons which take away focus from our team’s main goal.  I’m sure that once in a while there are software projects which are completed on time, but I’ve never seen them.  And as an old manager of mine used to say “Nobody gets fired by not getting the job done in time.  You get fired for surprising people that you didn’t get the job done in time.”

We don’t screw up by not meeting expectations. We screw up by surprising stakeholders when we don’t meet expectations.

In other words, as soon as we know our original goals are out of reach and we won’t live up to the expectations we set, move the goalposts.  Do it explicitly, and make sure that our stakeholders know.

I’ll never forget the first time I was telling a VP that the product we were building, that we said would be ready in October, was going to be done in February at the earliest.  This was for good reasons, but still it would mean a big delay before our company could realise the impact it was supposed to have.  He counted the months on his fingers and then said “We’ll that’s not acceptable.  What help can I get your team to make it happen earlier?”.  I was totally unprepared to answer that, because the only adjustment I had considered was moving the goalposts. Delivering what was promised, later.

It’s not that simple!  If the opportunity our product is supposed to grasp is time sensitive (to stay ahead of a competitor, for example), and should have a huge impact if done quickly, then delaying the release is the wrong adjustment to make.  Maybe there’s a key engineer working on another team that could join us, or maybe another team could pause what they are doing and collaborate with us. Maybe we need to break down the product and reduce scope, or maybe we can make some short term or “hacky” technical decisions which will save time.

I’ll call these adjustments ‘bad options’, because it is very possible that any of the alternatives we consider would have consequences which are not worth it.  For example, if we consider moving an engineer from another team to join the project, there is ramp up time associated with adding them.  Then, onboarding them splits the focus of the team, which increases communication overhead.  And of course there are implications of moving them from their current team, like down prioritising or dropping something else.  And sometimes problems just take wall-clock time to solve and increasing the number of engineers working on the problem might not help at all, maybe even make things worse.  We’ll need to evaluate.

Maybe it is worth it.  If one of these will actually help us do it faster, and the benefits of being faster outweigh the consequences of the “bad option”, then it could be a reasonable mitigation to the delay.  But if we’ve considered the different ‘bad options’ and their implications, and decided that the extra benefits are not worth it, we aren’t just giving up. We’re saying that the best mitigation is to delay the end date of the project, and now we’ve chosen to do so explicitly.

What we absolutely can’t do is recognise the risk and hope for the best.  When I raised with the stakeholder VP that we would be late, I luckily did so as soon as it was obvious. That gave us plenty of time to get other teams onboard to help, and this VP was able to help arrange that.  I still looked foolish in this meeting, but I learned that I can’t raise the alarm without suggesting possible mitigations.  And luckily I did so without surprising anybody, and without personal consequence.

Because when we pitch our ambitious product ideas and strategy, we are doing so with lots of uncertainty, and everybody recognises that.  It’s still a key part of the Product Manager’s responsibility to set realistic expectations, and often that means explaining that the uncertainty meant that our original plan will no longer hold.  But saying so isn’t as simple as saying “no, it won’t happen”.  Instead we need to say “It won’t happen under the current conditions”, and propose alternatives.  Alternatives which have consequences.  But it could be worth it.  And if it is, then we can achieve our ambitious, realistic goal.  Just with some tweaks along the way.

I think our latest episode is our best one so far ! Arvid and I met in person (!!) during the Swedish vacation period and had a chat about setting and managing expectations, with emphasis on saying no. Please have a listen, and reach out to us to discuss or debate on Twitter @productinternal or at podcast@productinternals.com ! And if you’re enjoying the show so far please follow!

And if you liked this post we’d love to have you join the Product Internals community! Subscribe for a new post once a week or so. If you find them as valuable as we find writing them please share them with your friends and colleagues!

Subscribe now

That is to say, I had no formal education and no formal training on Product Management. I felt like the biggest imposter as I put on the PM hat on in my first sprint planning meeting with my team. Without any foundational background to lean on I needed to use my intuition and common sense to work in a way which I felt would have an impact. Intuition which was formed from watching Irene and Johan. This got my started. Reflecting and learning from myself and my own mistakes how I’ve continued to grow.

In the latest episode of the Product Internals podcast, Arvid and I discuss tips we would give to a new Product Manager at three critical stages of onboarding (1 month, 6 months, 1 year).

Here are the three mistakes that I made early in my career, which helped me internalise the lessons which led to those recommendations.

1. Trying to have all the answers

It is the Product Manager’s responsibility to make ‘Product Decisions’, or decisions which affect how users interact and derive value from your product.  That’s true, sort of.  But if I’m a new Product Manager on a team then I definitely won’t be the best person to make those decisions.  The engineers, designer, data scientist, engineering manager, or literally anybody else who has been there longer than I have will have more context and therefore be more qualified to make those decisions, at least at first.

So I spent my first 6 months learning as much as I could about our product and the problem it was supposed to solve.  I read all the documents, I had 1:1s with all my teammates to learn the historical context.  I met with lots of users to understand how they were actually using and abusing our product. It was way different than we thought (of course!).  I learned like a sponge and 6 months in I could give a reasonable answer to pretty much every question about our product and strategy, either from the team or from stakeholders.  I had an explanation or justification for every challenge and critique.

In retrospect, that first 6 months was well spent.  This helped me ramp up tremendously and I was able to positively influence our team and product quickly.  But the critical mistake was thinking that it was a good idea to actually have answers.  My ideas and answers weren’t bad, I was never bullshitting.  I had varying levels of confidence in the things I was saying, but I did always believe that what I was saying was reasonable.  I would often get very insightful questions on something I had thought about just enough to have some idea and I would answer, but it was not necessarily an answer I had fully thought through.  And giving an answer in these moments effectively shuts down conversation.

Consider the person asking that insightful question. They are asking a question which is insightful because they have a lot of context themselves.  Quite often they have an opinion themself too, and I really want to hear that opinion!  If I give a half-thought-through answer to this person I risk losing what they can teach me.  And they would not only teach me what they see, but could also teach my team or others who might be listening like other users, stakeholders or leadership.

When you get a truly insightful question, the sort that stumps you a little bit, instead of trying to come up with an answer respond with this: “That’s a great question, I do have some thoughts on this, but what do you think?”

Having all the answers isn’t my job.  Making product decisions isn’t my responsibility alone.  Leading and empowering my team so we can do it together is the job.  And I need to learn from them, as well as from our users and stakeholders.  And together we’ll make the best decisions.

2. An implicit, verbal strategy that we “agree” on

After that first 6 months I started to form opinions.  I understood the bigger picture, how the problem we’re trying to solve fits in and why it’s relevant and important to solve now.  I understood how our product actually would solve this problem and what the future perfect world would look like after we’ve solved it.  I had a product vision in my mind.  I formed opinions on what the plan should be in order to actually achieve this vision.

I formed these opinions with the help of my team.  We had lots of conversations together as a team, as well as in 1:1s about the plan, and why we believed it was a good idea.  I pitched the plan to our leadership and stakeholders and they seemed to agree.  This plan was our strategy.  Everybody pretty much agreed that this strategy, that we had verbally aligned on, was the right way forward. Pretty Much.

Within my team, each person understood about 80% of the plan and 20% was confusing (this 20% differed from engineer to engineer).  In some cases I misunderstood the input I got from my teammates and created miscommunication.  In others I hadn’t explained myself well enough and they couldn’t internalise the reasoning that I had in my head.  The stakeholders were onboard but didn’t grasp the implications of what I was suggesting, especially since it required other teams in the company to do some work.

We broke down the strategy that we were pretty much aligned on into next steps and a roadmap.  Then something (un)surprising happened.  We started arguing about the finer details, about some peripheral use cases, about some tradeoffs we were making.  We argued a lot, and we had the same arguments repeatedly.  It was debilitating.  We did make some progress, and what we built did follow the strategy.  But on the more controversial points we were going around in circles.

The mistake I made was assuming this implicit, verbal alignment and agreement was good enough for strategy.  By simply writing the strategy down on paper, things improved drastically. I included the historical context, the justification for such a plan.  I also included the tradeoffs we had decided on making and why.  This took each engineer from 80% alignment to maybe closer to 95%.  And that remaining 5% was the same for everybody.  There was no more confusion or misunderstanding, we were aligned on what we were misaligned on.  Our productivity picked up almost immediately, and together we were able to pragmatically approach and resolve the unknowns and controversial areas.

Taking verbal alignment on a plan to a written strategy sounds like it could be unnecessary work if you are truly aligned already, but even still it provides a reference for all of us, including new members of your team.  It provides a single place (the google docs comments, that is) to ask questions, raise concerns, or discuss things we don’t fully agree with.  We still take these conversations in person but now we can be pragmatic about it and discuss the right things.  We share context faster, align faster, take decisions faster, build faster, and learn faster.

Have a great idea and a brilliant plan? Write it down!

3. Being Busy

As a Product Manager I have a lot of responsibilities.  I want to be a proper member of the product team and join stand-ups, plannings, retros and other team-local meetings and discussions we have.  I need to meet with users and stakeholders.  I am also a leader and am part of a leadership team within my department as well.  I am occasionally leading some large project where my team is a key part, which means more planning and checking in on the different workstreams to report progress and concerns to stakeholders.  Occasionally I am also hiring and need to spend time talking to candidates and interviewing.  The meetings pile up, and it's all very busy.  But that’s the job right?

But the work that I’m responsible for doesn’t really happen in these meetings.  I also want to dig into data, to consolidate and understand user research, to come up with and write down a strategy.  I probably should spend time preparing for quarterly and sprint plannings so I can lead the team in the right direction.  I need to read other strategies and documents which are floating around the company and are relevant to our product and my team.  And I need to spend time understanding the big picture, and how my team and product fits into it.  That’s also a lot, especially on top of the (un)healthy dose of meetings.  I was incredibly busy, but that’s the job right?

I did my best to squeeze the real responsibilities in between meetings. I managed to scrape by doing a good job, working very hard and getting done what I considered to be the bare minimum.  There wasn’t time for anything else!  I thought that being busy and filling up my time with meetings was the nature of being a PM.  Every other PM I looked at had a similarly full schedule, I had signed up for this.  Months went by without really being able to think about strategy and my stress levels were through the roof.  It wasn’t sustainable, and looking back at it now I wasn’t actually doing a very good job.

The mistake that I made was that I was not deliberate with my time.  I participated in everything that I felt like I should and I tried to do everything that I felt like I was supposed to.  But all together it was too much. Instead of being deliberate with my time, I could only be reactive.  I would spend time and energy on what seemed to be the current burning issue, and I’d give that my attention.  This meant that at best I would scratch the surface on what is really important and not let anything drop.  At worst, I would give no attention at all to the areas where we could have the most impact.  Trying to do everything (which was too much) was causing me to be reactive and drop things.  Trying to do all the different aspects of my job was ironically causing me to underperform.

But working at Spotify we are very fortunate to have some amazing coaches around, and I met with Thomas every few weeks for a coaching session.  We’d discuss the different things I was focusing on, the challenges I had.  He has the talent to help you to have some profound realisation by asking provoking questions.  We covered a lot of things in these sessions, but the one that really sticks with me is the need for self-reflection and planning my time proactively.

I started reflecting weekly on how the week had gone and what I wanted to accomplish the following week.  I also did something daily.  The weekly reflection helped me ensure that I actually was setting myself up for success to do the head-down work that needed to happen between meetings, that would require some focus time.  If I wasn’t, then either I would cancel some things to make time, or drop it and properly set expectations.

The daily reflection helped me stay on script, to ensure I was actually spending my time on the things which would lead to me accomplishing what I needed to.  We called it the 3,2,1 plan.  Each day I would decide 3 things that I wasn’t going to spend any time or mental energy on, 2 things that I would delegate, and 1 goal for the day.  It sounds simple but the impact was profound.

Being busy and ‘getting everything done’ isn’t the job.  Doing the right things really well, which means leading your team to have impact is the job.  Make sure that you are personally spending time on the things that lead to impact.  Be proactive with your time.

In our last podcast episode, Arvid and I reflect on our own experiences starting out, discuss tips that we have for a product manager in a new role different stages of the journey. Please have a listen, and reach out to us to discuss or debate on Twitter @productinternal or at podcast@productinternals.com ! And if you’re enjoying the show so far please follow!

If you liked this post we’d love to have you join the Product Internals community! Subscribe for a new post weekly. If you find them as valuable as we find writing them please share them with your friends and colleagues!

Subscribe now

There’s a lot wrong with this picture and a lot that went into it.  Most notably, nobody should ever feel like they can’t take vacation or that they need to check-in during their time off.  He could have followed the initial line of thinking and avoided vacation or never let himself properly disconnect.  But inevitably that would lead to increasing levels of stress, burnout and probably poor performance.  Sticking with that way of working has only two possible end states.  Either collapsing under the pressure, burning out, and eventually taking some sick leave.  Or the job stops being fun, poor performance reduces the opportunities, frustration grows, and Option B results in leaving the company.  Neither sounds particularly appealing.  It’s time for a change in mentality.

Let’s back up.  As a Product Manager, you must obsess about a problem, meet with users, absorb context, and learn as much as possible.  A Product Manager must synthesise this context into a mission, vision and strategy and then align the organisation broadly around them.  Users rely on you to understand their problems and prioritise solutions.  Your team relies on you to provide context problems so they can solve them.  Your team also relies on you to understand the impact behind every possible problem and to objectively compare them and prioritise.  Stakeholders rely on you for project management and communication.  Leadership holds you accountable for impact.  I have been the PM from earlier, and about a year into this role I was nearly crumbling from the pressure.

It’s a lot! Listing responsibilities and accountabilities like this still scares me a bit.  But I know that in my team I’ve got an awesome supporting cast.  The job description of a PM may sound like something I’ve described above, but nothing says that the Product Manager must do all of those things alone.  In fact, doing so would be irresponsible.  Spreading yourself too thin begins a vicious cycle.  You don’t have enough time, so you don’t onboard others to work with you. More problems and opportunities come your way but you don’t have time to onboard others, so you spread yourself even thinner.  I was irresponsible in doing this and nearly burned out.

There is one notable responsibility left out of the Product Management job description: Leadership.  Leadership doesn’t necessarily mean managing people or hiring, but it does imply building a culture and empowering Product Teams to be impactful.  An empowered Product Team doesn’t block on a Product Manager to do all of the above, they work together to do so.  An empowered team has the context to make good decisions and to communicate effectively with stakeholders too. They also understand the problem they're trying to solve well enough and believe in the strategy such that they could speak on behalf of the PM if necessary.  

Rather than continuing down the path of burnout, I chose a different route.  That way of working wasn’t sustainable.  Rather than doing everything myself I’d need to lead.  I need to make sure my Engineering Manager, other PMs I work with, and most importantly, my team have sufficient context to make decisions.  It is a mindset shift from ‘I’ to ‘We’.

It was a change in the way of working.  In general, I needed to stop doing things on my own.  Instead, I try to have a collaboration partner on all the important initiatives that I am responsible for.  This partner and I work together on the initiative from the start, such that they know it as well as I do.  Concretely, try partnering with an interested engineer on your team to meet with users and stakeholders.  Brainstorm ideas with this engineer, and eventually co create a part of your strategy together with them.  Do the same for the next problem, but this time with a different engineer.  When engineers join you in the problem space they learn invaluable context about the problem and become empowered to make some product decisions in their solutions themselves, without blocking on the PM or misunderstanding the users’ problems.

By working together with a collaboration partner for most of your responsibilities as a PM you make yourself fault-tolerant should you take vacation, get sick, or go on parental leave, but the benefits don’t stop there.  You get the power of two brains on the same problem and generally will do a better job together. You create a culture within your team of working with users and have a better chance of building what they really want.  And you remove yourself as a blocker or bottleneck in order for your team to make decisions and progress.

I changed my ways of working to be much more collaborative. Fast-forward 18 months later, and I actually broke my leg badly and needed to take sick leave for about a month.  There was no preparation and no handover conversations, but to my delight when I returned, it was business as usual.  The incredible collaboration partners I’ve been working with managed to cover for me across the board.  I made myself redundant.

‘Redundant’ sounds like ‘expendable’, but by working with partners, it becomes possible for a PM to focus where they can provide the most value.  It becomes easy and natural to delegate the rest.  Do less individually, keep your stress level under control, and together the team will have more impact.  So change mindset from ‘I’ to ‘We’.  You’re not the only one who can work on the daunting list of Product Management responsibilities.  Collaborate with others as much as possible and empower your team.  Don’t be a hero, be a leader.  Lead.

In last weeks Product Internals podcast, Arvid and I talk what we actually do with our time, as well as how we concretely make use of this way of working. Please have a listen, and reach out to us to discuss or debate on Twitter @productinternal or at podcast@productinternals.com ! And if you’re enjoying the show so far please follow!

And if you liked this post we’d love to have you join the Product Internals community! Subscribe for a new post every Wednesday. If you find them as valuable as we find writing them please share them with your friends and colleagues!

Subscribe now

In these situations the engineer on-call has two main responsibilities.  First, she communicates to users and stakeholders that something is wrong.  She creates an incident ticket, writes that 5% of requests on the platform are failing, and the 95 percentile latency is exceeding 500ms.  She mentions that the investigation is ongoing and promises to provide updates with more information.  She then sends emails to a distribution list of stakeholders, posts the incident ticket in the relevant slack channels, rolls up her sleeves and begins the investigation.

She logs into one of the servers.

cms-mbp:~ htop

The server slowly responds but CPU and RAM usage look fine.

cms-mbp:~ df -h

Oh snap, the disk is full.  Let’s check the logs.

cms-mbp:~ cd /var/log

cms-mbp:/var/log ls -alh

Oof some log files are several gigabytes. In total it looks to be about 475GB of log files.  Let’s tail the open log file and see what’s happening.

cms-mbp:/var/log tail -f myservice.log

June 30  02:23:14:01 cms-mbp com.foo.bar [INFO]: Blahblahblah

June 30  02:23:14:01 cms-mbp com.foo.bar [INFO]: Blahblahblah 

June 30  02:23:14:01 cms-mbp com.foo.bar [INFO]: Blahblahblah 

June 30  02:23:14:01 cms-mbp com.foo.bar [INFO]: Blahblahblah 

June 30  02:23:14:01 cms-mbp com.foo.bar [INFO]: Blahblahblah 

June 30  02:23:14:01 cms-mbp com.foo.bar [INFO]: Blahblahblah 

June 30  02:23:14:01 cms-mbp com.foo.bar [INFO]: Blahblahblah 

June 30  02:23:14:01 cms-mbp com.foo.bar [INFO]: Blahblahblah  

Hundreds of identical log lines every second saying. Ok, that looks suspicious.  She wonders, “is this normal behaviour? Is this something we introduced recently?”

cms-mbp:/var/log zgrep -c * Blahblahblah

Ok, this particular log line didn’t show up at all until Wednesday and then over 100000 times each hour after that.  This appears to be the cause for the big increase in file size.  “What did we do on Wednesday?” she wonders.  Looking through the git commit history, she looks at Wednesday’s only commit. The code looks fine, but she finds the suspicious log line and it’s pretty clear this is the code that is filling up the disks.

She reverts the commit, deploys and cleans up some old log files to make space on the full machines.  She watches the logs and graphs for another 15 minutes.  Things look normal and eventually the PagerDuty alert resolves.  Phew.  This is the second responsibility of the on-call engineer - putting out the fire.  Notice that she doesn’t try to fix the root cause in the middle of the night!  During an incident the priority is to restore your platform as soon as possible.  Generally this will mean reverting some code, not making a bug fix.  Now that the fire is out and the crisis is averted there is one last thing before bed. She needs to wrap up the communication.  She writes some details about the nature of the incident, declares it all clear, and goes back to sleep.

We were lucky in this situation because we had proper monitoring set up to tell us how our platform was performing.  We know our platform usually responds to requests in 30ms, and in this case responses took over 500ms for an extended period of time.  This measurement of latency is an example of a Service Level Indicator, or an SLI.  An SLI represents what performance the customers of our platform are experiencing at a given time.

We may also have established explicit expectations with our customers for what level of service they will receive.  These are Service Level Objectives, or SLOs.  SLOs are, by definition, more relaxed than the SLI reports under normal circumstances.  Things do go wrong sometimes, some latency spikes are ‘normal’ and transient.  Some are not normal and require an on-call engineer to wake up and intervene.  We can’t promise that our platform will perform ‘as normal’ all the time, but we can arrange and promise to have on-call and processes in place to keep the quality of service at a level that is reasonable for our customers.  This implies a necessary delta between an SLI and an SLO which gives the platform team some wiggle room to fix incidents before they have customer impact.  When the quality of service your platform provides to your customers becomes worse than the SLO you promised, then you have an incident.

But if your platform isn’t mature enough to have a properly established SLO.  That doesn’t mean your platform is immune to incidents. If it has users, those users have expectations.  If those expectations are breached in an impactful way, you have an incident.  You might notice this from your monitoring and alerting, you might notice it from customers complaining in slack.  Regardless, it's time to sound the alarm.

Once the fire is out, you have a golden opportunity to learn.  Technically, incidents represent quite interesting and obscure engineering problems.  Your team should discuss what happened and try to understand the root cause.  But for a product manager, this is also a golden opportunity to understand the impact that our platform product is having on the rest of the company.

A platform or internal facing product is at least one step removed from the end users, so the impact that an incident will have differs from use case to use case.  It’s easy for an internal user to assume that a platform they depend on will not have sustained outages and ignore the possibility.  This is why incident communication is so important.  Our users need to recognise the failure cases, and understand the impact the incident had on their products and users.  As a platform product manager, I need to understand how the users are leveraging our platform to give business value.  A platform product manager in a medium to large company is probably acutely aware of a small portion of usage which is the most important, but only vaguely aware of the rest.  The impact assessment of a major incident can provide the best data and insights into the broad value a platform product provides.

So after an incident, we had both a technical assessment from the engineers and an impact assessment from Product.  The problem may be solved but now the learnings must live on.  It’s time to analyse what happened together and learn from each other.  Have a post-mortem together with your team and impacted stakeholders.   Discuss the timeline.  When did the incident actually begin? When did we notice? When did we mitigate it?  Could we have prevented it if we had noticed earlier?  Are there other mitigations we or our users should put into place to protect against this from happening in the future?  Also discuss with your users the implicit or explicit (SLO) expectations they have for your platform product.  They might be misaligned, which could mean changes on either side.  Maybe it’s the right time to recognise those implicit expectations and make them explicit, setting an SLO.  If the expectations that users have on your product are not feasible to uphold then maybe your product is wrong for their use case.

So when things go wrong, it’s easy to focus on the negatives.  And the negatives may be very impactful for your product and company (although this means you’ve built an impactful product).  But in any sufficiently agile tech company the speed of innovation is well worth the risk of occasional problems.  And the learnings you get from these occasional problems can give such powerful insights, both technically and for your platform product.  The value you and your stakeholders get from the learnings might very well outweigh the impact of the outage.  Never blame an engineer for a mistake, thank them for giving you all an opportunity to learn from it.  Don’t fear incidents, celebrate them.  

In last weeks Product Internals podcast, Arvid and I talk about incidents, and the operational responsibility that a Platform Product Manager has. Please have a listen, and reach out to us to discuss or debate on Twitter @productinternal or at podcast@productinternals.com ! And if you’re enjoying the show so far please follow!

And if you liked this post we’d love to have you join the Product Internals community! Subscribe for a new post every Wednesday. If you find them as valuable as we find writing them please share them with your friends and colleagues!

Subscribe now

Unfortunately it’s not that simple.  Does the perfect product, the proposed solution make business sense?  How much time do you have to solve it?  Are you staffed to build the product well? Will this work with your legacy systems and existing tech debt?  There are constraints that you might be under from your organisation and business which could render the best product, the best solution, infeasible.  Ideally you build the best product possible, but you also need to be pragmatic.  The ‘best’ solution is the wrong solution if there is no pragmatic way to build it.

As a Product Manager you must always be evaluating the tradeoff between ‘best’ and ‘pragmatic’, and that means there are pros and cons for every decision.  Based on the constraints you are under, you may need to make concessions, cut corners, accept tech debt, or launch too early in order to maximise your impact.  These are potential consequences of satisfying your constraints.

But what are the consequences of not satisfying those constraints?  Answer that question too. A time constraint might have serious consequences if missed, like missing a Christmas launch for a retail product.  But maybe the deadline is arbitrary.  It could be something in between, like trying to minimise the ‘investment’ part of the ‘return on investment’ equation such that building the product makes business sense.  Similarly, if the best product wouldn’t be compatible with your existing systems, that doesn’t necessarily mean it’s the wrong thing to build.  It instead means that there is additional investment needed to adapt or redesign those systems before actually using the product widely. Not impossible, but a tradeoff to consider.  These constraints are actually tradeoffs too.

Engineering should help you understand the consequences of choosing a suboptimal solution, and you should help engineering understand why those consequences are probably worth it for the impact you expect to achieve.  Keep in mind that we’re building products under uncertainty, so there probably won’t be an obviously ‘correct’ answer.  Even though we’re using data to make decisions we are still making assumptions for which tradeoffs will serve us best.  And these assumptions can of course be wrong!  Check your assumptions regularly and identify what you’ve got wrong as quickly as possible so you can evaluate changing course. This is crucial for the relationship and trust between product and engineering.

So accept that you need to make tradeoffs when building and shipping a product in order to maximise your impact.  Start with the best possible solution and then evaluate the tradeoffs and concessions needed for pragmatism.  Align product and engineering on the decisions, staying open to the possibility of being wrong.  Build and ship a product. Solve a problem. Learn what worked and what didn’t.  Do it again.

In our most recent Product Internals podcast, Arvid and I talk about determine what to build next such that the team is executing on our strategy. Please have a listen, and reach out to us to discuss or debate on Twitter @productinternal or at podcast@productinternals.com ! And if you’re enjoying the show so far please follow!

At the core of a product team is of course the engineers. This is where the magic happens, where the brilliant ideas come from, where the product actually gets built and the problem actually gets solved.  You probably also have an engineering manager, you should have a product manager (my opinion on this is incoming), and you might have any number of supporting roles such as a data scientist, a designer, a user researcher, product marketing, or others. You might think that it is optimal to have each and every supporting role present on your team but as the size of a team increases so does complexity, so this is not necessarily the case.

If you are building platform products for internal customers or building a consumer product to be used by millions, what you need out of each of these roles changes.  If you are building an API, UX Design can help you ensure that you are solving the right Job-To-Be-Done for your users, they can help optimise the users’ workflow, and more.  If you are building a feature on a mobile app then UX design might be more focused on making sure the user interface puts the right information front and center and optimises the users’ workflow towards the most valuable content.  The Product Marketing needs of a business facing product like Microsoft Teams are entirely different than for the Experimentation Platform your platform team built internally (but don’t forget to market your platform product!). In some cases you’ll definitely want a full time professional devoted to a supporting role for your team. In other cases that might be overkill, but the needs don’t go away completely. Somebody needs to be digging into the data. Somebody needs to do user research, somebody needs to be thinking about the UX.

So if your team doesn’t have a dedicated UX designer, or data scientist, or product marketer you can’t ignore the need. Instead somebody will need to step into that role when the need is present. An engineer with experience digging into data can craft experiments, hunt for insights, and build a KPI dashboard.  A data scientist with some experience in UX can conduct user interviews and make recommendations.  A Product Manager with experience in design could absolutely fill that need if necessary.  In a product team we’re all in it together, our titles and official roles better represent our expertise, rather than what we should be doing at any given time.

And anybody with the right combination of expertise and interest can fill the role of the Product Manager too. The Product Manager is responsible for the ‘Think it, Build it, Ship it, Tweak it’ loop as we say at Spotify. The PM needs to ensure that each of these roles are played at the right time such that this loop is really a loop and moves in the right direction. Without somebody playing the role of data scientist to measure impact and validate/invalidate hypotheses, Build-Measure-Learn becomes Build-Build-Build. Without learning, the team will inevitably start building the wrong things eventually.  Somebody needs to be accountable for impact.  Somebody needs to be accountable for learning.

So in my opinion, every impactful team has a Product Manager, although they might not have that title. For a team to be impactful, somebody must regularly check in on what matters, validate or invalidate hypotheses, and measure that impact is achieved. Without somebody playing the Product Manager role, direction erodes and a high performing, impactful team becomes merely ‘productive’.  Building cool things is just a means to an end. Having impact is the real goal.

In this weeks Product Internals podcast, Arvid and I debate the different options for team composition in a platform product team, and also touch on a bit more product strategy and vision. Please take a listen, and reach out to us to discuss further on Twitter @productinternal or at podcast@productinternals.com ! And if you’re enjoying the show so far please follow!

Solving this problem becomes your mission.  All products you build, all efforts you prioritise for your team should be motivated and linked in one way or another to solving this problem.  It is the guiding star for your team, or your North Star Goal.  

And based on the hypothesis that forms your diagnosis, you come up with a Product Vision.  The Product Vision is a high level solution which based on your research and understanding of the problem, represents a future world where that problem is solved.  It might be in the form of a single product or more likely a set of products that work together to solve the problem.  They might be as tangible as something that you build, or intangible like a process or a culture.  It should be lofty and aspirational, without worrying about the details of what is pragmatic or easy to do.

Once you’ve painted the picture of the perfect world with this problem solved and described the products which you believe will solve it, it’s time to break it down. This breakdown starts a Product Strategy which, according to your research and hypotheses, should achieve your vision.  The Product Strategy doesn’t break down all the different steps needed to go from now to the Product Vision, and it is not prescriptive on the details or implementation.  Instead it represents high level coherent action in the right direction.  The Product Strategy may seem to go in different directions, but it should still be easy to link a recommended action to eventually achieving part of your vision and solving the North Star Goal.

But it’s also expected for the Product Strategy to be wrong, often! It’s all based on hypotheses and a coherent action can absolutely be to run an experiment to validate or invalidate your hypotheses.  The Product Strategy should be somewhat time constrained.  The level of uncertainty and the infinite time horizon of your Product Vision mean there is diminishing returns on how far you plan into the future. I recommend a time horizon of roughly 2 years for a strategy, although this is definitely not rigid.

Now, with your Product Strategy in one hand and the current state of the product in the other, it’s time to play the prioritisation game to determine what the team should actually be working on for the next little while. Now is when the details matter, although the Product Manager should not be prescriptive on these either. Work together with your engineers and other members of your product team to break down the coherent actions in your strategy into a roadmap. The roadmap is time constrained (I recommend around 6 months) and has less uncertainty, so it should be usable to set expectations with stakeholders. Now you are ready to go!

To anchor this with an example, if the problem you are obsessing over is the climate crisis, your North Star Goal probably is to have a sustainable society.  The product vision would likely be formed by several products which tackle the problem from different perspectives, such as climate friendly consumption, renewable energy, and maybe something outside of the box like space exploration. The strategy then represents the coherent actions we should take (based on our hypotheses) that are in the direction of achieving this, like advancements in electric cars, increasing the energy yield of wind turbines, and validating or invalidating our hypothesis that commoditising space travel is possible today.  The roadmap is broken down into the details of one or multiple of the strategic actions which can be executed over the next 6 months to a year (and I won’t embarrass myself by trying to think of what that might look like).

And this way of planning for multiple different time horizons with multiple levels of uncertainty may give the illusion that you have reached a higher level of confidence in what you will be working on. But it’s really the opposite. The real benefit of being problem obsessed, making a hypothesis that diagnoses the problem and suggesting ways to solve it (based on more hypotheses), is recognising all the different places where you could be wrong, and therefore have uncertainty that needs to be investigated. Stating your hypothesis, proving yourself wrong, and changing course is arguably the biggest responsibility a Product Manager has.

If the world around you changes, the verdict on the hypotheses and assumptions you’ve been working under might change too.  Your plans might become obsolete or insignificant.  In our industry where we live and die on the opportunity that new technology provides, our intuition and data informed plans will be wrong a lot. A well planned roadmap can be incredibly useful for productivity and a well researched strategy is super helpful to align your team on the link to the big picture. But don’t get too attached. Be ready to make the hard decision to toss the roadmap, change strategy, or even pivot to solving the right problem.

But it’s not that simple.  When you are building tools or platforms for engineers to do their job, if you introduce a new tool that they don’t like, they won’t want to use it.  The problem your platform product is supposed to solve isn’t new to them.  They’ve been solving it in a different way for a long time. They are probably very aware of the different options available, the pros and cons and the best practices.  They are well equipped to do their job well without, or maybe even in spite of your platform or tool.  Even if you can explicitly mandate that the engineers (your customers) use your platform product, that doesn’t directly translate into adoption.  They could push back because what you’re offering simply is not good enough, or they might drag their feet because they don’t want to use it.  They could say ‘not now’ for prioritisation reasons and be completely justified.

On the other hand, there can be very good reasons for centralising and standardising the tech stack and infrastructure in medium-to-large tech companies.  You can get reusability benefits, you can reduce the cognitive load needed to work on different components, the technical components will work nicely together.  These benefits represent an improvement on a global objective function, whereas teams choosing their tech stacks and tooling autonomously may only enable them to do a great job optimising for their local priorities.  These local optimisations might be a net negative on the global level, especially as you scale.  It’s an important tradeoff to consider between autonomy and standardisation.

So simply mandating that an inferior platform product be used doesn’t work very well, but at a higher level your organisation might need the global benefits that having standardised tech will bring.  It is the responsibility of a platform product manager to ensure alignment of these incentives, so optimising globally is also optimising locally.  In other words, the product that you provide should actually be the best tool for the job for your internal customers.

But the responsibility doesn’t end there.  Once you’ve built a product that successfully aligns incentives, the trick is to get your customers to see that too.  It’s such an easy mistake to assume this is obvious.  As the product manager for this platform, you are problem obsessed and understand very well why it is in everybody's best interest to use your product.  That’s not the case for your customers.  If they don’t understand why using your platform is the right thing to do, you’ll have the same problems trying to mandate adoption, no matter how good the product is.  This is now a marketing task. Market to your captive audience.  Help them believe.  Scale up adoption of your product as well as your impact without friction.  Market, don’t mandate.

We hope you enjoy the discussion!

In one of our 1:1 meetings around Christmas time, Arvid and I did some introspection on our careers and decided we should write a bit more to get our learnings down.  I ended up writing 20 pages or so and extracted the learnings that I’ve internalised from my 10 years in tech so far.  Arvid made a set of guardrails, which he describes as ‘The Bare Minimums’ of the PM job which he strives to keep in good shape at all times (spoiler, it’s a lot easier said than done!). We started discussing the conclusions that we’ve come to with our other PM colleagues and told some of the stories where we’ve made mistakes and learned.  We got some feedback that these discussions were really valuable and would be great to share with other new or aspiring product managers, so here we are!

Each week we plan on releasing a 30 minute podcast together with a short blog post which centers around a lesson or learning.  But like any good product managers we’re staying flexible, we’re open to feedback, and I’m sure we’ll experiment with different things and tweak the podcast, cadence, or content based on the qualitative and quantitative feedback we receive!

If this sounds like something you would be interested in please subscribe, follow and listen to the Product Internals podcast on Spotify (linked below), and find us on Twitter!

Enjoy!

Rob and Arvid