Subscribe now

Salary discussions are challenging. If a person asks for too much, they might seem greedy or out of touch with their own worth. If they ask too little, they might be undervaluing themselves, thus leaving money on the table. In this article, I’ll be discussing three occasions when product managers are engaged in salary negotiations and how to prepare for such events: being recruited for a job, getting new responsibilities, and yearly salary reviews. But before we get to that, I’ll paint a general picture of what can affect salaries and how those are drafted.

As a fair warning, while many of the facts captured here will apply to other roles outside of product, often, this article will narrow down to product managers specifically.

Location, company size, economic situation

First of all, and likely to the surprise of no one, salaries are heavily dependent on the geographic location, the size of the company, and the economic situation.

Switzerland, Luxembourg, and the United States have some of the highest gross average monthly wages, but of course, every salary needs to be compared to the cost of living, too. Urban areas and capitals with more company/talent competition often pay better, while smaller cities adapt to local expectations.

The bigger a company is, often the more budget it is operating with; thus, it can afford somewhat higher gross wages than startups or scale-ups, where some of the cash is replaced with share option packages. But the company size can also dictate different role expectations: a senior PM at a small company might be equal to an intermediate PM at a larger organization. A Group Product Manager or Product Director at a FAANG company can easily match a startup CEO role.

The economic situation also affects the job market and, therefore, salaries. Due to the economic instability in recent years and mass layoffs at even big-name companies, dropping demand for product (and many other) roles is observable. With generally more people looking for jobs, companies can afford to pay less (or offer a lower increase), as there is less fierce competition from other organizations recruiting talent away.

How product managers compare to other roles

Product managers are fairly paid at most companies: they’re part of the R&D organization, so they earn similarly to software engineers in the same seniority. This amount is often more than what people in other corporate functions earn, like communications, HR, sales, or support roles. Naturally, this can change based on what is in top demand for a specific market or industry — if there is a swarm of product managers but only a few talented developers (or, nowadays, AI researchers), that can change things.

Salaries for different job functions are also planned a year in advance, so the compensations depend on how the company performs and what’s expected. In a good year, bonuses will be given to employees; in a bad year, some people will not even get an inflation correction. This just underpins that there is no unlimited amount of money to distribute, and if more is allocated to salaries, then something else needs to be dropped.

In addition, people managers receive a guidance on effective salary ranges, both in the recruitment stage (where things are often more flexible), as well as for the later salary negotiations. Managers judge the salary to be awarded based on the person’s perceived seniority and expertise, their background and relevance to the job, their ask, how peers currently earn at the company, and how urgently they want to fill the position.

In most cases, the budgets are higher for new recruits than for existing employees, simply because it’s harder to recruit new talent than to retain one.

Being recruited for a job

When pursuing new job opportunities, we learn about the salary range from the company disclosing it as part of the job advertisement (they might be required by law in certain locations), or once we announce our expectations at the initial screening round. The latter is a standard process, so recruiters can figure out if the ballpark expectations of a candidate match with the company’s budget — if someone is asking for way too much, why continue the process?

Coming up with the salary number can be difficult, and product managers need to consider their relevant experience, the company’s location, the company size, and the overall economic situation. The more screening rounds someone goes through at similar organizations, the more awareness they gain about the salary figures. Recruiters rarely tell if a candidate is asking for too little (hiring agencies might because their compensation depends on the ask), but they will always signal if the number is too high. A reasonable strategy, especially when we know less about the market, is to ask for a slightly higher salary than what the right number seems to be based on the years of experience. Recruiters will tell if the ask is somewhat higher than what the budget is, especially if it’s not an unrealistic ask. And in turn, candidates can use this information to tune their compass for the next discussion.

In the recruitment process, candidates have one more opportunity to negotiate a better salary: before accepting the offer. As the offer might be higher or lower than what our previous ask was, or we could have learned more about the company, the role, and the overall compensation, it’s also the right time to pause for a moment.

Before we look at potential ways to negotiate a better offer, let’s state the obvious: challenging the figure can have negative consequences, like the company going with a different candidate or rescinding the offer, so tread with caution here.

The best offer negotiations are grounded in evidence:

• the candidate might compare it with their current compensation,

• how the new role expectations are different (if higher) than the previous one, or

• they might refer to discussions with other companies with better compensation.

Negotiating an offer is not unheard of, as long as the candidate’s counter is realistic. At best, the company will be able to match all or some of the ask; at worst, we’ll learn the limits of a role and our experience.

Receiving new responsibilities

Salary discussions might also be due when transitioning to product management from another function inside a company or just changing what we work on as a PM.

From other functions to product management

Product managers are not born ready; they come from all walks of life. Sometimes, there is a formal educational background, and other times, people get interested in related topics and end up in the role. When someone transitions from a different role into product management, there should be a compensation discussion.

As discussed earlier, product managers earn better than some other roles, and a company can’t expect someone to keep a previous salary but receive new responsibilities as long as they don’t already earn similarly. If companies don’t think an employee is ready to take on new challenges, they shouldn’t give them the opportunity. But if they assess someone as ready, they should match that with a reasonable wage.

To a more senior product role

Another type of transition is when product managers level up. They either start a people manager role after being individual contributors, or they get higher on the seniority ladder. In any case, it’s sensible to have a compensation discussion at this stage, too.

There could be cases when company promotions and salary adjustments are handled in separate phases (so one might not receive an instant wage bump), but those shouldn’t be over 6 months apart. If that’s the case, or the seniority change does not affect the salary, it could be a serious red flag.

To oversee different responsibilities

Roles can’t just change vertically (from a lower level to a higher one); they can also change horizontally (overseeing a different product area). Discussing compensation here can get tricky, as it often really depends on the exact case. That said, there are a few principles to keep in mind.

If the new role involves working with a bigger team, more stakeholders, or a more complex product area, that could easily translate to a seniority change discussed above. But if the new position is roughly similar in complexity to the previous one, it might be unreasonable to ask for a change in compensation. For example, companies do product rotational programs where PMs shift from one area to another every couple of months, and this doesn’t mean that they should be earning more with each change.

Yearly salary reviews

At most companies, there is a yearly performance discussion round, somewhat coupled with a salary review. In these sessions, employees and direct managers discuss what happened during the year, what individual targets the employee did or didn’t reach, and often, feedback from other colleagues. At the end of the talks, employees often get one of the three ratings: below average, average, or above average — although the exact naming or the number of the tiers can vary from one organization to another.

These ratings might be impacted by different biases, and employees can do a lot to affect the results, both during a year and just before a performance review. Eventually, the performance rating is connected with the salary review that follows.

As a preparation for both review meetings, product managers are advised to go through:

• The job definition/expectations of their current role

• Relevant company and individual goals set earlier and their progress

• Key achievements from the period with specific examples

• Public recognition from colleagues or external parties

• Projects/impact delivered beyond job expectations

• Any forms or questions provided as part of the process

Being conscious and vocal about one's own achievements is important during the review meetings while remaining sensible. The best advocate for ourselves is often our own self, and having a prepared discussion with the direct manager will also enable them to vouch for us, especially if it affects compensation.

Companies operate with defined budgets, and this is the same case for salary increases. The additional salary budgets are often broken down to functions, which then, broken down again to specific groups, and finally, to individuals. People managers often have a say in how their “salary increase” budget should be allocated among their direct reports.

This is when performance ratings come into the picture, as it’s unlikely that everyone will receive similar amounts. While some companies use stack ranking to come up with best and worst performers, others follow a more flexible approach, where the manager mainly decides what score to give and how it translates to salary changes. Being mindful how we rank compared to peers in similar roles can also help provide context about our own performance.

One last aspect to consider for yearly salary reviews is inflation. A few markets have regulations in place to automatically compensate for inflation every year, but it’s far from a common standard. If such a measure is not included in the process, consider the local inflation when discussing any compensation adjustments. As $50 from five years ago is now worth less in terms of purchasing power.

Conclusion

Salary discussions can be challenging, and one needs to be prepared with enough context about the market, the company, and how similar roles are compensated.

The three scenarios covered in this article (recruited for a job, new responsibilities, yearly reviews) provide an overview of where most conversations take place and how to handle specific parts of the process—where someone could push for more and where it’s unrealistic to get a significant wage bump.

When discussing wages, it’s always advised to treat the topic with respect, both to the manager and to the organization. Budgets are not infinite, and one company might have valid reasons to offer less/more than another firm.

And while new recruits often have more leverage in negotiating salaries (where the company has an urge to fill an opening), keeping a good, ongoing employee-employer relationship also depends on how the parties feel about the right level of compensation.

Subscribe now

Product managers often launch new features, but sometimes, they get it wrong. Occasionally, they launch a functionality that is not validated enough, does not solve a real challenge, or simply will get ignored by customers. And it won’t be an imminent issue, but it can be one of many paper cuts.

It’s okay if an uncooked feature slips through the cracks a single time and gets into the real product. Maybe even a few times is okay. But if this happens repeatedly, it will eventually bloat the product and make it very hard for that company to innovate.

Why?

First, these tiny features will hurt the discoverability of real value-adds, the things that are making the difference in your solution. The information architecture will suffer, and users will drown in the sea of features.

Second, in a sizable company, every single feature will get some adoption. Maybe it’s an accidental click now and then, but it’ll show up on the metrics dashboard as utilization. And after that, it’s a lot more effort to sunset the functionality than it was to build it.

Third, the total cost of ownership is always more expensive than the feature development itself. Fixing bugs, writing documentation, and educating new joiners about some functionality that almost no one uses. Unless the startup goes bankrupt in a year.

What to consider when launching new features

You can build new features in many ways. Doing months of research, building based on a hunch, seeing an opportunity on the market, copying the competition, or even just providing what those loud customers have been asking for.

If it doesn’t solve a real pain point, enable new opportunities for a good chunk of your customers, or progress the product vision, it’s just a nice to have. And too many nice-to-haves will eventually kill your product by a thousand paper cuts.

Know when you’re working on incremental improvements for too long.

Maybe that colorful loading animation is making a lot of users happy. Maybe it’s making just the product team happy? There is nothing wrong with some confetti in your product, but if that’s what is being built most of the time, ring the alarm!

Consider that product managers, especially the empowered types, have a lot of control over how they spend the company’s resources. If they work with a team of 6 developers, with an average yearly salary of €80.000 (US figures can be much higher), that is already close to half a million in a year. A house with 3 bedrooms and a garden can be bought for less in many countries. Is your investment also that long-lasting?

Deprecating features is difficult

Let’s imagine that you’ve fallen into this trap and launched a couple of functionalities that are just bloating the product. Or maybe it was your predecessor.

Now, how do you get rid of those?

At the very least, you need a good product vision and product leadership who is committed to building something good. If you don’t have the vision, you will lack the compass that guides you in the right direction. You’re trying to go north, but you might be heading south. If your leadership doesn’t care about keeping the product complexity in check, you’ll be building new features instead of being allowed time and resources to mow the grass.

In the short term, removing useless features will hurt a bit. It’ll affect your team as they must do all the work and communication. It’ll be painful for selected customers who really love those functionalities.

But if you’ve picked the right things to eliminate, most will never notice what’s gone. In return, your product will get focused. Instead of 12 mediocre things to do on the page, you’ll have a great 5. Instead of 15 clicks to get to the results, your users will only need 9.

And after all this, you can go back to building what moves the needle again!

Subscribe now

Product management is about solving customer problems. In most discussions, two types of problems arise: common and unique problems. While common problems are easier to address (how the search works, what shape the profile picture should be), solving unique problems will contribute more to an organization’s success.

In this article, I’ll cover what common and unique problems are, how to recognize the type of a challenge, and effective ways of dealing with unique problems — from mapping out constraints to testing possible alternatives.

But first, let’s clarify the definition of these expressions.

Common and unique problems

Common problems are solved by many existing products in one way or another. Things like how picking dates works, how to label things, or the basics of tabbed navigation. While the details might be a little different, the core concept is the same, and the best practices are widespread.

It’s easy to take inspiration from another product and apply similar principles to ours. Common problems and their solutions are typical examples of don’t reinvent the wheel if it already exists.

Unique problems, in contrast, are specific to a company or an industry. They’re not solved by many other organizations, so the approach can’t be copied. Problems like how to moderate content on scale, how to reduce a computer’s power needs, or how to make paint dry quicker.

Often, it’s more important to solve unique problems well than to have a perfect answer to common challenges. As in many cases, a great solution can make a product win over the competition. Just remember how many people use “googling” instead of “searching”.

Google recognized that the performance and quality of search are equally important.

So why should we recognize unique problems?

First, to focus on what really matters. If someone spends long hours coming up with a solution to a common problem, that’s most likely a wasted effort. Common problems rarely need huge investments because good patterns are already publicly available. We just need to pick one approach and fine-tune it to our liking.

Second, unique problems need systems thinking. When solving complex problems, we need to consider how different alternatives can affect a whole platform, what aspects of existing solutions might need changing, and what features will be affected.

Third, as discussed above, the solution to unique problems is just more important to get right. Getting them wrong at best will cause some user experience friction, but at worst, it can tank a business.

When doubting the nature of a problem, try the following questions:

• Has anyone done something similar inside our company? (Integrating a new data source to a data pipeline might not need a new approach.)

• If not, has anyone done something similar outside the company, but within the industry? (The way to handle customer complaints for reservation systems might have its unique attributes, but might not be a completely unique problem. And it’s easy to benchmark how Booking.com or Airbnb is handling cases.)

• If not, has anyone done something similar outside the industry? (Large language models were first used for specific use cases, but then they spread out to healthcare, finance, marketing, and other industries.)

If there are no good solutions to benchmark, we’re likely dealing with a unique problem.

Solving unique problems

When drafting some search functionality, the design of the search bar is less of a question, as there are well-established patterns for that. But how the results are displayed or what can be considered relevant are the points to spend time on. But unless someone is building a Google competitor, the feature doesn’t need a lot of unique thoughts — so at the end of the day, it’s a common problem.

In contrast, unique problems need a different approach.

1. Constrains mapping

A great solution requires a very good understanding of the challenge. Get acquainted with the details of the problem, the wider context, and map out possible constraints. Does the team know enough to come up with a great solution? If not, this is a good opportunity to dig deeper.

Maybe there are some hard technical limitations (maximum number of API calls), or there is a product decision you need to respect (in what cases user data is deleted).

Consider here both product logic and technical constraints, but don’t treat them as unchangeable. Every now and then, good solutions require challenging existing patterns.

2. Time allocation

One anti-pattern of a well-thought-through solution is rushed decision-making. Maybe there is an internal deadline, or an executive would want to see progress by a given date. Unique problems need detailed thinking, and it’s hard, if not impossible, to come up with the best way to solve a difficult problem in hours.

Ensure that the team has ample time to understand the details of the situation and come up with at least two alternative solutions.

Why two? To avoid falling into the trap of going with the very first idea. And the two approaches should be unique, not just two different designs of the same solution.

3. Low-effort testing

Once the team has settled on a few ideas, test them out in a relatively low-effort way. Hallway testing, quick-to-build prototypes, or even drawing user flows on paper can work here. Find something that doesn’t take days to work out, but would enable you to present the ideas to others. Colleagues who are aware of the area are the best to contribute here, as they are already in the context.

In terms of the time investment, follow a 70-30% rule: if it took 7 days to come up with the solution ideas, spend no more than 3 days to test them out.

Working with the ideas hands-on is also a great opportunity to see how many edge cases the alternatives would create. If too many, chances are that it might not be the best solution to the problem. Or that some constraints need to be changed.

4. Solution decision

Once the feedback is in, it’s time to pick a solution!

Select the approach to move forward with based on the feedback received, your hunch, and the overall development effort — and in this order.

If there is a clear winner, and it aligns with the initial belief, then there is no question that the team did a good job solving the problem.

If there are very different opinions, but your gut is telling you to go towards one specific solution, trust that feeling. Product professionals develop good instincts over time in their area, unconsciously evaluating decisions from different angles.

And, of course, consider the development effort too. It can happen that the best solution requires the biggest effort. If that’s the case, weigh the effort vs. the consequences of going with any of the other choices. If other options would create more pain in the future than comfortable, maybe it’s worth picking the first approach.

Takeaway

Product managers deal with a lot of decisions every day. While some are less important, others require thorough thinking and evaluation — just like unique problems.

The most important thing is to recognize them. There are a few things that set them apart from more common problems. Most importantly, that their solutions are not straightforward.

Once we find a unique problem, we can address it by taking a look at the context, spending some time crafting solutions, coming up with multiple approaches, and then validating the idea with other people around us.

And remember, when it comes to common problems, don’t reinvent the wheel.

Subscribe now

Backlog grooming or refinement is the act of enhancing, estimating, and prioritizing the possible work items of a product team. So, what’s usually wrong with those ceremonies? Many things!

First, backlogs are often ever-expanding lists, slowly becoming the facades of real prioritization. In theory, the backlog is there, nice and groomed. But in reality, it’s messy, contains outdated items, and it’s hard to figure out what really matters outside of the top few things to be addressed next.

Second, the ceremony becomes a too comfortable habit through regular meeting invites. Just because the team is “agile” and many colleagues came from places where there was a backlog refinement before, there needs to be one here too. But is it checked whether the team really gets the benefits out of such a session?

Third, discussing and estimating new items take up too much time. Since many backlog items will never get delivered, teams spend an excessive amount of time discussing and estimating. Why spend this effort per item if most of those will never see the light of day?

What’s on your backlog?

To understand how to combat the effects mentioned above, first, we need to take a look at where backlog items are coming from. Often, there are two sources: new product requirements and technical items.

Here, product requirements define new solution ideas, problems to discover, and other wishes. On the other hand, technical items are more specific improvements that can help scale, enable new capabilities, fix bugs, or improve the way to develop software.

Both types of items are valuable, but should they be on the backlog? The scrum guide describes “product backlog” in the following way:

“The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.”

At best, it’s a blurry explanation.

But one thing this definition DOES NOT state is that the product backlog should contain all the possible work items and half-baked ideas. And that’s the first mistake product teams can make with backlogs.

It’s easy to fall victim to recording all the good ideas (from which there are usually many) to avoid forgetting them. But in reality, most items won’t get addressed in the short- or medium-term. So then, the backlog becomes a collection of far-reaching ideas mixed with actual, near-term work that is important to carry out.

And that’s very messy to handle!

On top of this, if the backlog is treated this way, every additional grooming session will just make it harder to separate actual priorities from the noise.

Ideas are not equal to next priorities

To avoid a convoluted backlog, keep ideas in a separate place. Use the backlog to visualize the next few months of planned work in priority order.

While this sounds easy in theory, it needs rigor and thoughtfulness in practice.

First, set up a place where it’s easy for everyone to record new ideas. You want to make sure that it’s also fast to convert ideas to work items and the other way around. We want to remove friction from the process, and if an idea’s details need to be copy-pasted every time from one tool to another, the approach will likely never get adopted. An additional Jira status, a spreadsheet with different tabs, anything works as long as there is enough separation.

Second, product requirements and technical ideas can be stored in the same place, although I’d recommend separating, grouping, or labeling them. A new feature idea with customer insights is very different from addressing technical debt. Plus, putting the items into topical buckets can ensure that the list remains navigable and it doesn’t just become a bloated list of forgotten ideas.

Once we have separate backlog and idea buckets, check that everything is in the right one: ideas that might not happen until next year shouldn’t be on our backlog, and things we’re addressing next should be clear, visible, and prioritized. For this, let’s define a backlog timeframe: how many months of work we’d like to keep in the backlog.

I’d recommend 3 months—one fiscal quarter.

Then, go through the legacy backlog once to move out all the ideas from there. This will be a long and tedious exercise, but one that’s worth it once. And this again signifies why it should be effortless to transition work items to ideas.

After we’re done with the one-time exercise, future backlog refinement sessions should be more critical. When evaluating new items, those should only make it to the backlog when we’re confident they’ll be dealt with in our defined timeframe.

Almost every new item is a good suggestion, but we cannot deliver everything as all teams have limited capacity. A few questions that can aid the decision-making here:

• Is this something that we’ll confidentially tackle in the next X months?

• Is this something that’s necessary for our planned deliverables?

• If we take this in, would we need to deprioritize something else? Would that deprioritization affect any major plans or commitments?

• What happens if we don’t address this in the near term, or at all?

• Why didn’t we plan with this before in the first place?

• If we delay this, can we still reasonably expect to hit our goals?

After asking similar questions, we should have a hunch that something should go to our backlog or be recorded as an idea. One response we might receive to these is…

“But it’s a quick thing, let’s do it now!”

Which is fine, as long as not every second or third item is like that. There are quick wins that are better addressed on the spot rather than waiting months and losing the context.

For the estimation, we shouldn’t spend too much time guessing the size of the ideas. The scope there is often fuzzy, so estimating them this early is not practical. Instead, use T-shirt size estimations (S, M, L, XL) or task/story/epic distinctions to understand the effort. That’s probably enough at this phase.

Next, let’s look at how to keep the backlog and the idea lists organized beyond the recurring backlog refinement ceremony.

Going through the whole thing once in a while

To ensure that the backlog and idea lists remain relevant and manageable, we should allocate some time to review them at least every few months.

For the backlog, even if we’re strict about moving items there, we might still end up with a few things that we thought were important but ended up not doing. This is normal, and a casual review is an excellent opportunity to revisit priorities—and if some backlog items should be rather moved to ideas. These issues can be minor technical improvements or features that just never got to the top.

In addition, a recurring review is needed with the idea list(s) too. While we’ve purposefully deprioritized items in the past, we might have discovered additional needs since then. If that’s the case, it’s reasonable to move some items to our backlog or plan with those for future quarters. And, if we realize that something has already been addressed, the idea item can be deleted.

When working with a product team and recurring delivery cycles (like a quarter), the best time to revisit the ideas section is before the start of the next cycle.

The backlog and its ranking are good reminders that there are no separate priorities for technical items and new product requirements. We have one team, and they must decide whether to work on the next best features or address something technical. And product managers should be able to adequately prioritize the upcoming work with technical leads.

Key points

Remember the following to make sure that there is a good focus in your product team:

• Store product requirements and technical ideas separately from the backlog. The backlog should only contain items that will be confidently addressed in the next few months.

• Be critical about new items during the backlog refinement. Remind yourself that most ideas are good, but any team’s capacity is limited; therefore, you need to prioritize.

• Go through the list of ideas once in a while to see what to consider for the future. There might be timely, hidden gems or even items that are no longer needed.

Subscribe now

Google Stadia, the search giant’s cloud gaming experiment, has lived for 3 years and 2 months since its launch in November 2019. Even though the product didn’t get the mass adoption the company was hoping for, its shutdown should be a benchmark for other companies and product managers: refunding most purchases, letting users keep usable hardware for free, and compensating game developers.

What led to the sunset, and was Google’s gaming business model ultimately flawed from the beginning? In this article, we take a look at how the service started, what promises it made, the economics behind it, and key takeaways from the shutdown process.

A lot of promises, a spotty track record

Upon launch, Google detailed a lot of ambitious plans for Stadia: launch a game from a YouTube ad, the ability to jump into exact game moments via a link, the Google Assistant helping players beat games, shared multiplayer worlds, 8K resolution, and more.

The company certainly set high expectations for itself.

Something that might have been needed to differentiate itself from rivals at launch, but also something that had trouble living up to. Google could not deliver even half of these promises in the end. But it indeed delivered a solid gaming experience with not too many bugs—as long as players had a decent internet connection and latency.

And Stadia improved the service’s accessibility a lot over time.

The cloud gaming service started with a subscription-only option limited to 14 countries, costing either $10 per month or a $130 hardware bundle with 3 free months included. But in 2020, it introduced a free tier (pay once for a game, then unlimited play in high-definition resolution) and expanded to 22 territories with a big European push.

Beyond convincing game studios to port their work over to Stadia or release exclusives, Google even tried to create its own internal game studio, SG&E. However, that was shut down in early 2021, hinting that the company might be winding down investments for the product and refocusing the service as a technology experiment. Which the search giant eventually confirmed in early 2022, repackaging its technology as a white-label product.

And in September 2022, after trying to enhance, tweak, and repackage its offering, Google announced that it’d shut down the consumer version of Stadia this January.

But before we get to that, let’s have a closer look at Stadia’s business model.

The challenge to scale

Google faced the classic ecosystem challenge: in order to get more users to its service, it needed more content. But to convince game studios to bring their content, it needed more users. (Remember the Windows Phone app ecosystem’s challenge?)

And the search company failed to get to scale on both fronts.

Stadia featured roughly 300 games just before the shutdown. This could have been enough, but the catalog mainly contained games from indie developers beyond a handful of well-known titles. In contrast, Nvidia’s “GeForce NOW” supported 1500 titles while also working with a different business model—more on that later.

Google didn’t communicate any player or revenue numbers for Stadia, so we can only estimate what the service reached at its peak. Based on media reports, the department’s leadership aimed for 1 million active users by the end of 2020, which it missed by ~25%, putting active users somewhere around 750k. Among these, a forecasted 160k “pro” subscribers.

For comparison, GeForce NOW had 20 million registered users in late 2022, which are, of course, probably not all actively paying customers.

Google likely needed the scale to offset its investments in Stadia. While the company had mature streaming tech before from YouTube, building up a game streaming service must have required a significant effort.

By calculating with 1 million users purchasing two game titles for $30 each for every year, and an additional 200k yearly subscribers, Google could have generated $84 million yearly revenue.

And out of that, the search giant could have kept only $25 million—dividing the revenue number with the standard industry revenue split formula of 70-30%.

Even if this had been a yearly figure (and the reality was probably lower), it wouldn’t have been enough to fund further development profitably while maintaining the servers and other running costs. And this number, next to the company’s $257 billion revenue for 2021, can seem like a rounding error.

In addition, Stadia’s business model might have been flawed from the beginning.

After the rollout of the free tier in 2020, users were granted unlimited playtime of a Stadia-purchased game. And the prices were comparable to other game stores, with the exception that all others required an adequate gaming computer to play with those titles. So Google bundled in its streaming tech for free, indefinitely. Or that was the plan.

Meanwhile, Nvidia’s competing service:

• was able to work with already-owned games (or let users purchase new ones),

• monetized the streaming tech ($10 per month for the same access that Google offered for free),

• and introduced some additional technical limitations.

And for the game studios, the setup didn’t require significant adjustments. It likely worked out of the box if their titles were compatible with other platforms. Nvidia figured out that for a scalable business model to work, there should be a lower barrier to entry for both players and game partners. And that additional set of functionalities Google dreamed of just added complexity to both parties.

Stadia’s graceful shutdown

In September 2022, Google announced that it was shutting down Stadia:

“…while Stadia's approach to streaming games for consumers was built on a strong technology foundation, it hasn't gained the traction with users that we expected so we’ve made the difficult decision to begin winding down our Stadia streaming service.”

And the news was interesting not just because the search giant was axing another of their services but also due to how its cloud gaming ecosystem has worked:

Stadia sold digital copies of games only available through its interface and technology. To a degree, it’s comparable if the Google Play store would shut down, leaving users unable to update or use their phone apps—just on a smaller scale.

So what would happen with users who’ve purchased games via the platform?

It’s a tricky question. Google chose the better but more expensive route, refunding all purchases for games and add-ons since the launch of its service. With one exception: subscription fees that enabled 4K streaming and game discounts were not returned.

On top of this, the company even committed to refunding all hardware purchases that were bundled with the game service at any point, including Chromecasts and game controllers. Heck, Google even went so far as to enable a long-requested Bluetooth support for controllers via a browser update to avoid them becoming e-waste.

The company did more than a fair job of satisfying users. But they were probably expected so to avoid losing customer trust or an additional investigation into Google’s market dominance.

Players got decent refunds (sometimes even multiple thousands of dollars), and they got to keep working hardware that can be used for video streaming or gaming.

On the other side, Google took the monetary fall for game studios. The company paid its share to them from the revenue-split agreement while also refunding end-users the total purchase price. The only disadvantage studios might have experienced is if the Stadia porting costs were more expensive than the incoming revenue from the platform.

Or if they’ve developed an exclusive.

A prime example to follow

While Stadia might have had a flawed business model, the way how it executed its product shutdown is remarkable. There are a couple of lessons in the decisions made that are useful to consider for other companies, especially in product roles:

1. When starting a new product, think about possible doomsday scenarios. What would happen if there is no product-market fit and the product needs to be sunset? The Stadia team likely had a script for that, considering the nature of the business.

2. Communicate clearly and frequently. Do not let rumors spread before an official announcement, and provide a complete answer to key questions. Google shared concrete steps it will take, outlining the shutdown process. It didn’t have all the details but provided deadlines for addressing those points.

3. Make customers as happy as reasonably possible. The company has customers using different services of theirs, so it cannot afford to ruin its reputation. While making everyone happy is impossible, try to do justice by considering what you’d expect from the other side. And that often means going beyond what’s strictly required by the law.

For the Stadia shutdown, Google respected its former motto: don’t be evil.

Subscribe now

Platform product management requires different skills than a traditional consumer PM role. When a product team is building a platform, they need to consider the expectations of multiple internal teams and find ways to push the right things forward. Most platform teams only indirectly create customer value. Instead, they empower other teams to move faster and develop frameworks around common product needs.

There is a unique challenge with platform products: if you build the wrong thing or the wrong way, the team quickly becomes a bottleneck, delaying other teams’ progress. For example, just think about a data platform team that is busy fulfilling specific requests from other teams instead of building an actual platform capability.

Over the years, I participated in and observed different kinds of platform product work: a marketing automation engine, data reporting functionalities, and scaling a multi-million user booking system. In this article, I’m sharing my learnings on approaching the various phases of platform product teams.

And it starts with an adequate situation.

1. A situation arises

Most platform product teams I worked with were born out of a business challenge. Maybe the company realized that they built the same things over and over in the past, and it’s just not efficient. Or it could be that executives are not happy about the time-to-market speed. Or, in case of ambitious market expansion plans, the business might be just planning ahead to handle the growth.

In any case, there is a situation with untapped potential.

Experienced product professionals should recognize an opportunity when it makes sense to change things around and start investing in platform work. But before teams do that, a fair warning: platform capabilities are not always the solution.

There is a difference if something happens for the fifth time in two years with more to come. And another where the challenge is the second instance only, with no expected recurrence. In the latter, we don’t need a platform.

A good mental test of whether a company needs standardized capabilities is to consider how much duplicated work teams deliver. And we shouldn’t only think about the developers here. Are the product and design functions working on very similar problems in different groups? Do they create solutions that are oddly close to one another?

To identify whether you’re in the same situation yourself, ask the question: is the problem/solution you’re working on only relevant to your team?

If not, maybe it’s time to start discussing it.

2. Convincing top and bottom

Selling the idea of a platform product team is challenging.

First, measuring the opportunity in terms of revenue impact is almost impossible, and the value created is often indirect—enabling other teams to build faster.

Second, when trying to sell the need for the platform capability, we should not be just pitching the idea to leadership. But we should involve developers early on who would be counting on the work of such a team.

Telling it to developers is not only good for communication but can also be validation. If our subject matter experts don’t see value in platform capabilities, that’s a telling sign that we might have interpreted the signals wrong. But if they agree, they can be a powerful ally in convincing others.

Taking to engineering, product, and business leaders requires a different approach. We should focus less on the technical capability and more on the benefits of a platform product team for the business. What would a team like that enable in terms of efficiencies, time-to-market, and growth?

We should prove how the new team will be able to reduce product development resource needs in the long term. So, developing software faster or with fewer people. Ideally, both. This way, the organization can become leaner, or existing colleagues will be able to focus on more meaningful initiatives.

3. Planning the effort

If our initiative is built on solid grounds and we’ve received a leadership buy-in to proceed forward (at least an initial one), now it’s time to forge a more detailed plan.

First, document the high-level vision of what you want to achieve, including key milestones. The plan doesn’t need to be too detailed. While we want to provide a direction, we don’t want to spend too much time working out all the details—talented people will take care of that in time.

And speaking of people, the next logical choice is to assemble the team. Here, it’s either having extra headcounts at our disposal or making changes to existing teams—possibly, removing people from less important initiatives. For a platform product team, we need staff members who can navigate well within complex frameworks, as the team will eventually be building those frameworks for others.

Another important aspect of planning is keeping the timeframe in mind.

The scope will look vastly different when planning for one or three years ahead. Even when building a three-year plan, the focus should be on building the biggest value-adds first. And the longer the timeframe is, the more chances the project will have for disruptions. Periodically following up on milestones will have an immense effect.

One fundamental goal of platform capabilities is to provide value early to other teams. Therefore, it’s unwise to waste time on nice-to-have functionalities that look good on the surface but solve tiny aspects of the core problem.

In addition, if an organization had teams building similar solutions before in silos, it’s likely that the new functionality won’t be immediately on par with those previous capabilities. And that’s totally fine! Instead, take learnings from earlier attempts to avoid repeated mistakes. And put the focus on where it matters.

4. Keeping the focus

As with all software projects, there will be roadblocks and challenges on the way. We should be wary of our time and resources to ensure spending efforts smartly.

Keeping focus is crucial when building initial platform capabilities.

It’s easy to allocate two days to something that’ll look nice, especially when working on a three-year project. But the more often that happens, the more delay will be piled up.

Ruthless prioritization is required when building platform solutions. There are always more ideas than capacity, so we should be mindful of what to say “yes” to. Choosing one priority over another doesn’t only mean spending an amount of time building something. It also blocks us from doing anything else that is potentially more rewarding.

The question is: does it worth it?

As with any product, a platform product team will also need to say “no” to many good ideas that are just not worth building for others at a given moment. It’s not that a suggestion would be irrelevant; it just means that right now, there are initiatives with a bigger impact.

5. Maintaining the solution

Once platform products reach a mature phase, teams building them shift focus to maintenance. Instead of quickly adding new capabilities without too much of a risk, teams will need to balance scalability, reliability, compatibility, and future needs.

At this point, at least a few internal teams rely on the platform. Scaling the service to their needs is essential, especially if the utilization is continuously increasing.

Think of additional registered users, new documents created, or new bookings in a reservation system. Any of these would mean that a service not only needs to manage existing items but must also handle the additional load.

In terms of reliability, the platform product should be constantly available. The team must prepare additional safeguards for peak load times, malicious attacks, or any major internal mistakes that can bring the service down. If the product is a data platform facilitating requests for other teams, an outage is critical.

Efforts around compatibility should also not be ignored. Developing a mature platform product means that, over time, different teams might have integrated with the solution in different ways. Any change to existing APIs, endpoints, or other capabilities has to be aligned with other internal teams using those. We could win a lot here if the team enforced tight control of those interfaces in the past, preventing faulty or overly outdated integrations.

And last but not least: handling new requests. This task can already sound daunting in addition to the points above, but if a team wants to stay afloat, they need to invest reasonable time into three things:

• Building new things for others: To continue better enabling other teams, the platform product team will need to create new capabilities. What are the functionalities that would make the most impact? Again, building any product involves saying “no” to many good things, and this is especially true when maintaining a framework. On top of this, new requests can also increase the overall product complexity, making future developments more challenging.

• Building new things for themselves: Creating tools that enable supporting the existing platform product—better reporting, improved alerting, or a quicker way to achieve a recurring task. Writing documentation and organizing internal knowledge-share sessions is also part of this effort, as the team wants to be prepared to provide the best support.

• Deprecating underutilized functionalities: Maintaining functionalities, fixing bugs, and just dealing with the increasing complexity have a bigger cost than developing any single feature. No team can carry the weight of an ever-increasing product. Platform teams need to invest in reviewing parts of their offering and make wise choices about what not to support in the future. Removing an underutilized feature can make space for something new.

Keeping a platform product healthy and prospering over long periods of time is the true test of any product manager. Success requires strategic thinking, being constantly connected to other teams, and making informed choices.

Takeaway

When managing a platform product team, identifying the correct stage can help us make better decisions, resulting in better business outcomes. All teams start with an opportunity that turns into conviction, planning, focus, and then finally, maintenance.

It’s a bit like building a feature, just bigger.

If you’re in a similar role, remember to focus on key use cases, not edge cases or single-team requests. What are the opportunities with the biggest impact? And how can you enable the team focus on those with minimal disruptions?

Subscribe now

Being a product manager includes working with a lot of hypotheses and supposed facts. In product discovery, we want to validate key questions to ensure we’re building the right thing. This process isn’t easy if we’re working alone or with a small group. But creating clarity becomes even more challenging if we need to align with a lot of other people.

On the one hand, we want to collect everything in one place that we believe in. On the other, we should ensure that others see the same picture.

While writing a product discovery document helps, the important part is to agree on what has been validated with high enough confidence and what needs more research. And we need certainty, especially if the effort to build the product is significant.

One way to map out the confidence levels is to use a product confidence matrix, a three-by-one sheet that puts hypotheses to three different columns:

• What we want to figure out: items with low or no confidence, where we don’t have the expertise, or topics that we haven’t looked into before.

• What we suspect: medium confidence ideas that we might want to reconfirm.

• What we know: items with high confidence, where no further validation is needed.

Here, we graduate items from left to right once we have confident answers to the questions. The items’ size also matters: more important questions are bigger, indicating their significance. It’s also recommended to focus on bigger cards first and only validate smaller ideas if that’s a reasonable investment.

Even if we get the smaller details wrong during product development (a small part of the user flow, placement of some explanation…), it’s easier to correct those than if we make a mistake with a bigger one.

The main benefit of the product confidence matrix is that it’s shared with others. In the beginning, all essential stakeholder from the product discovery should add their thoughts to the sections (high, medium, low). Once done, the alignment starts: discussing the items’ perceived level of confidence.

The discussion part is vital. During these alignments, we can surface our stakeholders’ context on the topic, or if they have a different viewpoint. And if they do, it’s a good opportunity to share theirs with the rest of the audience, thus, potentially eliminating some guesswork.

Product confidence matrix with an example

Let’s suppose we want to build a new task management app, something similar to Todoist, Google Tasks, or Any.do. Here, we can start writing down our key hypotheses about what our target group would want to see in the product.

Do they need a quick way to delete tasks? Are keyboard shortcuts necessary at the beginning? Should the product support recurring tasks?

After this is done, invite key collaborators for a discussion, presenting what’s assembled:

In reality, it’s rare to have alignment at first, so let’s assume this is not the case here.

When discussing the items, it turns out that there are divisive opinions around the “undo” functionality. Some people in the room argue that it’s highly needed; others challenge this, saying that if it’s easy to add or delete tasks, the feature wouldn’t be a top priority. Finally, the audience agrees to move this hypothesis to the low confidence zone, so more research is needed.

There is another debate around the possibility of live collaboration. A few participants highlight that most to-do apps don’t have this functionality, so it cannot be too important for the first version. Again, the group settles this by moving the idea to the medium-confidence zone, requiring smaller amounts of confirmation.

Lastly, a participant who worked with AI systems before added a suggestion that AI recommendations are needed with high confidence. Others disagree; they argue that while an AI-powered tasklist would be great, the concept is too broad, and the effort might be too much. To resolve this, the stakeholders move this hypothesis to the low confidence zone, marking this for validation.

After the changes, the product confidence matrix takes its final form.

The collaborators see the same picture at once, and the product teams working on the discovery will now be putting effort into the relevant questions. For simplicity, the card sizes were the same in this example, but they should be different in reality, to indicate the items’ significance.

Takeaway

Coordinating product discovery work with many contributors needs effort, especially for major solutions. At this point, individuals cannot just trust that everyone has the same context and knowledge. Some proactive action is needed to align the group.

The product confidence matrix takes the guesswork out of alignment. By agreeing on what we want to figure out, what we suspect, and what we know, we can ask the right questions and, hopefully, get down to the right answers.

Subscribe now

Recently, a lot of changes happened at Twitter. Much started with Elon Musk getting more interested in the platform, buying stocks of it, joining its board for a few hours, then sending a letter of intent to acquire the company. Quickly after, Musk tried to walk back on this goal, blaming misreported bot numbers as a cause. He finally acquired the company, partially to just avoid an uncomfortable trial. And since then, many new product initiatives have been started, and half of the global staff has been fired.

Messages from the earlier court materials let us peek into Musk’s fundraising style:

• Elon Musk: Any interest in participating in the Twitter deal?

• Larry Ellison: Yes… of course 👍

• Elon Musk: Roughly what dollar size? Not holding you to anything, but the deal is oversubscribed, so I have to reduce or kick out some participants.

• Larry Ellison: A billion... or whatever you recommend

• Elon Musk: Whatever works for you. I'd recommend maybe $2B or more. This has very high potential and I'd rather have you than anyone else.

• Larry Ellison: I agree that it has huge potential... and it would be lots of fun

In the article below, I’ll be going through the rumored changes to Twitter, what those may mean for the platform, and highlighting some of the coming risks and opportunities.

But first, let’s start with how Twitter is doing as a business.

Twitter’s business not doing so well

While Twitter was founded in 2006, it didn’t turn to profit until late 2017. And even then, the profitable years didn’t last long, with 2019 marking the last one.

In the earnings call for Q2 2022, Twitter published a revenue of $1.2 billion (1% year-over-year decline), but $1.5 billion in costs (31% year-over-year increase). With a workforce of around 7.500 employees globally, the business was not doing so well.

Twitter mainly relies on advertising as a source of revenue, around 90% of its total income. The remaining 10% comes from data licensing and other revenue streams.

And when Musk sent his offer to take the company private for $44 billion, he effectively valued the company at $54.20 per share. As a reference, Twitter’s stock traded at $39 on 1 April, just before Musk disclosed his stake in the company.

After the acquisition, just in the last few days, Twitter also warned employees that “bankruptcy is not out of the question” for the company, so they should expect aggressive timelines from Musk.

The Tesla owner’s plans so far

After sending the first offer, but before actually acquiring Twitter, Musk said quite a few things about what he plans to do with the company. He said he wants to democratize free speech, that making money out of Twitter doesn’t matter, and that he wants to build an “everything app”. This is something similar to China’s WeChat app, where users can message people, take care of mobile banking, pay for items online, play games, or post videos—so they can take care of almost everything.

And on the night of 27 October, Musk completed the acquisition of Twitter.

In the few weeks since then, the Chief Twit surely made a lot of changes to Twitter as a company and its product plans. While he originally stated that he was not buying the company to make money, one of the first initiatives points in the other direction: making Twitter’s subscription service more expensive, Twitter Blue.

The new version has started rolling out in some markets already and offers a verified check mark along with other upcoming benefits, like boosted post ranking, for $8 per month. And that’s the same blue check mark that was previously only held by well-known companies, celebrities, and other notable individuals—indicating authenticity.

Another idea that Musk instructed engineers to look into is to bring back Twitter’s failed short-form video startup, Vine. The startup was acquired by the social platform in 2012 but was shut down in 2016 due to lackluster growth and adoption. And seemingly, Musk is not only interested in short-form video but also in long-form too. Leaving public comments that point in both directions.

As a declared “free speech absolutist”, Musk also plans to open up Twitter by cutting back on the level of moderation on the platform. Originally, people questioned whether he’d bring back previously suspended users instantly, but in reality, all that happened so far is that he started to set up a moderation council.

And just a few days ago, Twitter fired 50% of its employees due to cost-cutting. Another sign that Musk actually cares about how much the company makes.

Last but not least, most recently, Musk detailed how he’d plan for Twitter to enter the payments space in an employee all-hands: making something like a “Twitter balance” available inside the platform and accepted by selected online partners. Plus, providing a debit card that works for offline transactions.

A product manager’s perspective

Twitter as a platform started shifting into something new mere weeks after Musk’s acquisition. This might get fans excited or critics worried—including companies who are spending big bucks on advertising.

My take? The company is moving fast with a leader who is not caring about corporate etiquette. But it’s also exploring many different product directions simultaneously, which doesn’t look good for an unprofitable company.

The new Twitter Blue will create an elite circle of people who are willing to pay $8 per month to stand out from the crowd, both visually and algorithmically. So probably, there will be a decent interest in the repackaged service, and I’d expect Twitter to make more money out of it than from the previous version. But still, not a ton.

People like to pay for fancy online badges—just look at the early NFT market.

But as Casey Newton highlighted, there might be some problems around the math:

“Other employees have warned about a secondary feature of the new Blue that Musk added at the last minute: reducing ad load in the Twitter app by half. Estimates showed that Twitter will lose about $6 in ad revenue per user per month in the United States by making that change, sources said. Factoring in Apple and Google’s share of the $8 monthly subscription, Twitter would likely lose money on Blue if the ad-light plan is enacted.”

One challenge about the offering’s blue verified checkmark is that previously this symbol was only held by notable individuals and companies whose identity was Twitter-verified.

Now, the blue checkmark may mean two things: a verified user or someone paying $8 per month. Unfortunately, users won’t be able to figure the difference out unless they go to the user’s profile and tap on the symbol for an explanation.

Or maybe they would? Twitter rolled out an additional “Official” badge for verified accounts, but then Musk killed it, and then Twitter rolled it out again. Again, within days.

As expected, abusers took the very first day to prove that a blue checkmark without verification might raise a very real problem. Quite a few accounts changed their names to the likeness of brands and celebrities, posting content that would be unexpected from the real accounts. And this might hurt advertisers’ interest to spend on the platform if Twitter cannot guarantee brand safety. Especially bigger companies that are more likely to be targeted by bad actors.

If you thought Twitter had a crypto scam problem, think how big it can get now.

With the recent events leaving only ~4.000 employees in control, and a top leader who likes to dictate priorities and has very high expectations, Twitter remains a sizable company that is required to move with the speed of a startup.

This is definitely not Marty Cagan’s empowered product teams in practice, especially if photos of employees sleeping on campus are circulating online.

While some temporary rush can be expected with the owner change, Elon Musk is clearly bringing a new culture to Twitter, something that he has developed at his other companies. And the one that doesn’t include working from home.

Twitter surely needs new revenue streams to turn to profit again and have enough cash in the bank to finance the ambitious growth Musk is dreaming of. The platform will likely rely on advertising money for many years to come, but it’ll be interesting to see how much it can gather from subscriptions. While the new Twitter Blue is a start, its earnings won’t reach the levels of the primary revenue source.

Subscription businesses usually don’t cross a certain percentage of total users. For example, even YouTube, with its 2.1 billion monthly active users, only gathered 80 million paid subscribers for its YouTube Music and YouTube Premium packages (including trials) which leaves paying users at 3.8%.

But Twitter has a strong incentive to make more money, and Musk will take every reasonable opportunity to do so, even if it brings trouble with the law and regulations.

Will Twitter follow LinkedIn’s playbook and open up more messaging and insight functionalities for a good price? One can imagine having to pay for Twitter to message people outside our circle, better statistics, and features for power users.

But this is still far from the Chief Twit’s “everything app” plans. And the recently discussed initiative to turn Twitter into a bank is months (if not years) away.

To start growing the business again, Twitter needs aggressive user growth first.

But some users are fleeing the platform and looking for alternatives like Mastodon. So the question is: can Twitter keep its user numbers under control and start growing again?

One thing is for sure, Twitter will be changing fast in the coming months. It’s like an oversized product experiment: will the new version work better than the old one? Time will tell.

The social media platform needs to transform while keeping its users and advertisers happy, so the revenue keeps flowing in. And at the same time, kick off ruthless cost-saving initiatives.

If Musk wants to reach $26.4 billion by 2028, better keep track of that revenue!

Subscribe now

Chances are, you’ve been part of a project where the expectations were much higher than the reality. Plus, as a customer, you’ve also probably been promised something by a company that wasn’t fully delivered.

It’s always better to get more than what you expect. It’s not so fun the other way around.

In this article, I’ll be looking into how the underpromise-overdeliver strategy can work out for product teams, its disadvantages, and how to overcome a situation where the expectations have already been set sky-high.

The challenge with estimations

An incorrect estimation is one of the key reasons software projects are not completed on time. But estimation is difficult, and the bigger an initiative is, the more chances there are that something will be miscalculated. Or completely forgotten.

When estimating work, we can face different types of complexities, and these definitions originate from the Johari window model:

• Known knowns: we know what to do and how to do it (maybe we’ve done it before), so we can provide a confident estimate.

• Known unknowns: we know what’s coming, but we don’t know how to carry it out. So while it’ll be part of the estimation, it might be under or overestimated.

• Unknown unknowns: we’re not aware that some new kind of work will be needed. Thus we cannot estimate it, nor calculate a proper buffer.

During project planning, a team should strive to estimate what is known and identify most of what has been “unknown unknown” before. This and a healthy amount of buffer can go a long way to set correct expectations towards an initiative.

Setting expectations

A product team must manage two kinds of expectations: internal and external.

Internal expectations are coming from the organization. From marketing, sales, leadership, and from external partners we might be working with. These expectations mostly revolve around scope, timeline, and cost.

Good product managers also communicate what’s excluded from the scope, as part of these expectations. When reading a solution description, different people will assume different things, and it’s a good method to align others on what not to expect.

One of the most critical misalignments is if there is a gap in the understanding between the product team and the company’s leadership. For example, if the senior executives are expecting something, but the team is planning to ship something else, it’ll eventually result in a blowback.

If we notice a situation like this, we should course-correct as soon as possible!

It’s better to admit a mistake than willfully mislead others, knowing that something cannot be reached—even if we were not setting those expectations up in the first place.

Nokia lost in the smartphone race partially because management was afraid to communicate the truth to the top and instead painted a more rosy picture of the state of business.

But the strategy of underpromise & overdeliver is not suitable in all scenarios.

When pitching a new initiative or team, we want to be as realistic as possible. A too-ambitious timeline might get us in trouble, resulting in failed expectations if we can’t deliver. On the other hand, being too pessimistic might cause the project to be rejected—before it could have started.

And now, let’s talk about external expectations.

When communicating to customers about new functionalities, one mistake is to set expectations too high. Of course, there is nothing wrong with creating some hype, but too much publicity could easily backfire.

The video game, Cyberpunk 2077, is a notorious example of creating too much hype. The development studio behind set gamers’ expectations too high by promising previously unseen, next-generational gameplay. But when the title was released (after eight months of delays), initial reviews quickly pointed out the buggy game experience. And then, the studio needed to spend the next months mitigating the issues.

Another mistake organizations make is to communicate a too-ambitious timeline.

There can be many unforeseen complexities in software projects. By a general rule of thumb, the more complex a product is, the more chances there are for complications.

Even well-known companies like Apple or Google fall into the trap when announcing new solutions, and then it turns out that the project is more complex than initially thought, like Apple Pay Later.

Sell the product, not the roadmap

Product roadmaps can be a great communication tool with customers, especially in B2B. The roadmap can kickstart discussions on customer priorities and expectations, and if presented with the correct narration, it can be powerful equipment to validate the product direction.

The product roadmap is the prototype of the product strategy, similarly as design prototypes are a visualization of new functionalities. But many people use roadmaps the wrong way.

Generally speaking, customers should buy the product because of its capabilities today and not because of what’s promised for the future. Roadmaps are not commitments, and they shouldn’t be treated like one.

And paying customers are also not early investors, providing funding for an idea.

When companies sell the product roadmap, they’re onboarding customers with high expectations, with the promise that those roadmap items will be delivered, in the initial timeframe.

But that’s rarely the case.

Instead, these clients return a few months later, taking the company accountable for its promises. And then, the company needs to explain its way out of the previous commitment, give steeper discounts, or risk churning the customer.

In a recent Reforge program, Jeff Dwyer, former tech lead at HubSpot, shared how the company handled roadmaps and in-development functionalities a few years ago: the sales team was not allowed to show roadmaps to (potential) customers. Even the product teams were only permitted to demo and talk about solutions internally that are already running in the production environment.

This was HubSpot’s method of not selling the roadmap. And a few years ago, the company even featured the following statement on its “what’s new” page:

“As we like to be transparent with our customers, we want to include a reminder that while we endeavor to continually develop our software, we do so in an agile way. This means that even our best-laid plans get adjusted. While we do expect to develop and improve our products, we can’t promise any specific features will be delivered on any specific timeline, including the features discussed above. We hope you’ll buy the product for where it’s at today and continue to see value over time. This means that you should not decide to buy based on a feature being made available in the future.”

Mitigating an overpromise

Let’s face it; overpromises happen from time to time. And no matter if we made those commitments originally or not, it’s better to correct them than let the situation slide.

First, identify what’s the reason for the mismatching expectation.

Did someone promise too many features or subproducts that just don’t seem realistic now? Was it an overly ambitious timeline for a priority project? Something else? Once a root cause is identified, try to mitigate it by looking at the scope-resource-time triangle and the possible opportunities.

Second, have there been any external commitments? If so, how strong are those?

There is a difference between mentioning a new feature in an informal discussion, promising a solution to 20+ customers, or making contractually binding commitments.

At worst, we have to face financial and reputational consequences for the commitments that we can’t fulfill. But those are very rare cases, and most overpromises have a limited impact.

Being transparent about failures and delays can also be a good thing. And if those are done in an honest way, they can even build trust towards our company.

Conclusion

So how can we avoid failing our own expectations?

We should aim to overdeliver, not overpromise. Better estimations and proper expectation setting help a lot, but we also shouldn’t be afraid to adjust expectations if those are wrong in the first place.

And when discussing plans with customers, remember: we want to ensure that the current product is providing value and avoid selling an idea that might or might not come true. Customers are not early investors funding a dream.

Underpromise & overdeliver is not always the most effective strategy. If the situation requires a fair portrayal—like presenting to leadership for budget approval—we should do our best to paint a realistic picture.

And last but not least, overdelivering can take many forms. It doesn’t always have to be new and powerful features. Sometimes, it’s things that positively surprise customers: subtle animations, cheerful images, or a unique voice in copywriting.

Subscribe now

Do more people equates to less time? Or, as the classic saying goes: can nine women deliver a baby in just one month? The second example perfectly illustrates the messy product management triangle: scope (1 baby), resources (9 women), and time (1 month).

Is it possible to add more developers to a specific problem to improve time-to-market? What about out-scoping some nice-to-have items from the functionality? Or should the organization accept a month of delay?

These factors usually come up in product delivery discussions, especially if someone from management wants to speed up the development of a particular feature.

So what can the team do to make it happen?

There is no perfect formula to figure this out, and the answer usually comes with a compromise. Nobody will be thrilled; everyone will feel they’ve given up something.

But while the scope-resources-time triangle looks pretty straightforward at first (“three words cannot be that difficult, right?”), every aspect of it needs a different approach.

Scope

The scope of a functionality covers the number and quality of features, the level of technical excellence (built as a robust solution vs. hacked together), and overall the amount of work put into it.

It’s easy to suggest out-scoping items if there is time pressure, but the question is: would the feature still be as valuable—or very close to that—as customers expect them when they’re paying for it?

Just imagine paying for Netflix or Spotify and think about what percentage of the content the services could safely remove before you start to question the price.

It’s similar to when customers figure out whether it’s worth paying for your product.

Alternatively, the team can consider cutting from the quality of the features: what if the new service only offers 5 fonts to start with instead of 15? Or just 10 basic drawing shapes instead of 20?

While these are easy compromises in theory, we rarely face similar decisions in real life.

Out-scoping functionalities from a future product can still be a reasonable way to ensure timelines are met, or the company can deliver something ahead of competitors.

The key question people should be asking is: does the feature still make a difference? Is it addressing the core part of the problem it is supposed to address? Or is that a stripped-down version of the original idea that just checks all the boxes for a “delivered feature”?

If a too big compromise is made to the scope, it can affect the expected business results, thus making it harder to justify additional investments into the solution later. And then we can think about: was the original hypothesis so wrong that it failed, or does it have to do with the number of trade-offs?

Resources

Resources in this triangle are often attributed to the headcount (people), but that’s just the biggest portion of it. It’s also the infrastructure, the tooling, the office renting costs, and maybe some free food or drinks.

Scaling up from 10 to 5000 customers requires not only more people but also a bigger paycheck to our technology provider: more servers, bigger data needs, and potentially a faster way to deploy product changes.

When developments are time-pressured with a given scope and timeframe, people’s first idea is often to throw resources into the problem. But new people don’t grow on trees, especially not people who would already know our technology and business.

For example, reallocating one or two developers to achieve something faster can make sense if those engineers don’t require a significant onboarding effort, know the technology and business context, and if the task is manageably-sized.

In every other case—especially if a person is hired from outside the company—it takes time to onboard. Learn the business context, the technology frameworks, how the products work, and all the abbreviations.

In many white-collar roles, half a year is easily considered good to reach peak productivity levels, so “throwing resources” to the problem should be mostly a long-term approach. And welcoming someone new to the team also requires existing members to invest time in training and guidance.

So adjusting resources in the scope-resources-time triangle is the most challenging aspect of the three, as even exceptionally skilled people are not plug-and-play lightbulbs.

Time

The above-mentioned triangle works in a way that two factors are usually defined, and the last one comes as a result of an equation:

• Set resources and scope? Then the team will come up with a delivery estimate.

• Agreed resources and time? Then the scope will be shaped accordingly.

With most empowered product teams, the resources are the least flexible aspect, usually dedicated by the management. And teams can balance the scope and timing.

Oh, if we’d have just one more month… but do we?

In case of delays, the deadline is the easiest factor to push further. If the team miscalculated something, how much of a problem is to do the release a few weeks later?

And the answer usually depends on earlier commitments and market factors.

Have there been any internal or external commitments made about the functionality? External ones are the hardest to change. For example, if some date or tight time range was communicated to customers earlier, they’d have those expectations. Not meeting those can cause reputational damage or churned customers at worst. Especially if broken promises are a repeating pattern.

Failed internal expectations can also be damaging but to a more limited degree. If there are no external commitments and the market is not pushing us to strict timeframes, only personal reputations are at stake. Even if a timeline was promised to the upper management, if there are no real stakes involved, pushing deadlines further only requires admitting a miscalculation.

Of course, if competitors are trying to beat us to market, that’s a different thing. Launching something brand new first can be a game-changer. Launching the same thing a few months after a competitor still has value, but reasonably less.

And challenging timeframes can also be a management tool.

If used correctly, it can dare dreams to consider alternatives, think about value-adds, and shape the product scope sensibly. No product is ever truly finished, and setting boundaries can help teams to think about delivering incremental value.

Making decisions based on the triangle

The scope-resources-time triangle is a simple framework that hides many intricate details with its obviousness. When making product delivery decisions, keep in mind that:

• Resources are the hardest to change; if it’s not a small or a long-term challenge, looking at other aspects might work better.

• Adjusting the deadline is relatively easy, but doing that too often erodes the organization’s trust. Time can also be a good tool to avoid scope creep.

• Scope cuts make sense, but only if the new product/feature’s core value proposition remains unchanged. Removing half of the features rarely results in the same experience.

Think from a customer’s perspective: if you were on the receiving end of a new solution, would you be happy with the compromise that was made?

And no, nine women cannot deliver a baby in one month.

Subscribe now

Onboarding as a product manager takes time: it’s required from the role to understand the business strategy, build good relationships with key stakeholders, be an ambassador of customer problems, and also work well with the dedicated team.

Being efficient in learning the ropes is a key advantage.

Over the years, I’ve onboarded multiple companies and teams as a product manager. Each time, I tried to improve my mental process to onboard, structuring the onboarding process to be more efficient.

In this article, I’m sharing my six-step framework so other product managers can leverage it, no matter if they’re joining their first company, the second team inside an organization, or the fifth company.

Step 0: Invest in self-learning

Before taking the first orientation meeting with someone else, review the available materials about the company or the team.

If you’re joining a new company, search for articles the organization has published about its way of working, how it develops software, other job descriptions (the roles a product manager will likely work with), or the values the company deems important.

If you’re switching to a new team internally, there should be a breath of knowledge readily available. Internal materials describing previous development items, the roadmap, product discovery documents, and other materials on what has happened before.

When going through the materials, note anything that stands out or feels odd.

First, fresh eyes are the best at identifying new customers’ challenges when using a product. Second, if there are some non-self-explanatory items, usually there is some history behind those, so it’s handy to write those down for later discussions.

Step 1: Introduce yourself to key contacts

There are usually some expectations on what a new product manager should achieve in the first months, and it starts with knowing the right people.

Ask your manager early on what roles the product manager should closely collaborate with and who these people are for the given product area. Once this list is secured, try to schedule introductory conversations in the first few weeks.

You don’t have to know everything about your responsibilities or get a deep understanding of the product to have these discussions. Just show a friendly gesture and ensure that others know that you’re here now, so they can count on your expertise and involve you in the right discussions.

The key contacts here are not just higher-ups. Ensure that you also focus on other departments like partnership, marketing, or other product managers that you’ll be likely working with.

These discussions will give you a few pointers on what documents are important, where you should put your focus, and which projects would need your contribution. Build an efficient system to organize all these learnings.

Step 2: How the company and the team operate

By this time, you’ve done some research, looked at some materials, and had a few discussions with relevant stakeholders. Next, understand how the company and your team operate.

Start from a strategical level, discussing the company’s mission and strategy with peers, and slowly narrow down into operational aspects: how the company makes decisions, who decides about what things, and how you’ll be able to resolve potential conflicts.

Most important of all: understand how the product manager role connects to the business, and what most people expect from the role.

And it’s not just about the process. Get a better understanding of the company’s financials, how the organization makes money, its business model, how profitable each product is, and what drives the adoption.

As some business acumen is expected from product managers, it’s important to be aware of key business metrics. And you’ll likely make decisions that will contribute to the company’s bottom line.

On a team level, get familiar with how the team works, what ceremonies it organizes, and how the product manager is working with other roles. A typical question here: who is responsible for the way of working within the team? Is it the product manager or the engineering manager?

Step 3: Past, present, future, and other teams

In the next step, try to understand how the team contributes to the wider company goals, what they’ve done before, what’s planned for the future, and how other teams rely on your work.

Learn what the product team has recently worked on, what fueled those priorities, and the original hypotheses behind them. A new product manager won’t always agree with people who’ve previously held the role, but it’s important to know the reasons.

After then, focus on the present, and get your head around the current projects, how current initiatives are progressing, and who is expecting what from them. Often, some promises have been already made about milestones or completion dates—if not externally, at least internally.

Don’t be afraid to question or challenge previous approaches! As a product manager, your job is not to just blindly execute but to make sensible decisions given the context.

Last, when looking into the future, get familiar with roadmaps and future initiatives. While it’s too early to doubt the entirety of those plans in the first weeks, eventually, validate whether you’d make the same decisions.

Plus, don’t forget to map out how your team’s work connects to other teams. If the overall product is complex, chances are high that frequent collaboration is needed with other teams to bring new solutions to the market.

Step 4: Research notes & talking to customers

After getting familiar with the business, how the team operates, and the existing plans, it’s time to spend more time with the main stakeholder of a product manager: customers.

Going through the previous steps is essential to getting into the right mindset. While talking to customers might sound like something that you’d want to do first, starting those conversations without proper context setting could be harmful.

Before you participate in the first customer meeting, review notes, research summaries, and other past feedback gathered. This information will get you up to speed on the major pain points from key customers and help to frame better questions next time.

Always have a goal in mind for customer meetings, but don’t be afraid to go off-script. While most of the discussion should revolve around a well-defined topic, customers might have other impactful needs. Ensure they’re given enough space to explain those—as product managers want to focus on the most pressuring problems.

Customer sessions are also good occasions to see what users like about the product. Unfortunately, these meetings are far too often focused on problems only, and it’s a breath of fresh air to ask about the positive experiences. Plus, product people can also take away a lot from the discussions: get an idea about what works well or might be driving retention.

Step 5: The product manager takes ownership

By this point, a product manager is aware of what’s happening and should have gained enough knowledge to feel more confident in the role. This is a good moment to take full ownership of the product area and consider the onboarding completed.

Work with the team on daily delivery activities, start to discover the next best opportunities, and shape the product strategy. You don’t have to know everything; just ensure that you know who to turn to if something unexpected comes up.

Gradually, a product manager should be less dependent on others when making decisions and be able to solve most situations without managerial escalation.

Remember, the learning will never be fully complete!

Create an environment where you can navigate the complexity without knowing every single product detail. Instead, focus on what’s important, and learn everything else just when you need them.

Step 6: Measurement & user behavior

While the onboarding might have been completed, there is one more important area to know more about. As product managers become fluent in navigating the new role, they should also spend more time analyzing what works and why. Start by looking at satisfaction and adoption metrics, and understand how customers use the product.

Which are some of the most popular functionalities, and where do users spend most of their time? What features have increased utilization, are flat, or are on the decline?

Establish a baseline of a healthy adoption and test how each feature measures compared to that. Use organizational standards if you have any. Otherwise, come up with your own thresholds.

While some product work will always be centered around new opportunities, existing functionalities also need attention. If something is not producing enough value, it should be addressed: reworked, improved, or killed. And it’ll be your decision to make a choice!

Relevant data points can also be powerful for decision-making. But PMs will eventually encounter cases when the needed data is not available. Don’t get too carried away with measuring everything; focus only on what matters!

If you identify a significant tracking gap, improve that, but it’s not worth having an overly detailed measurement plan. Think about what data you’ve looked at in the previous months; if you haven’t something, that’s a good indicator of its importance.

Also, be mindful when using data to make decisions, as data in isolation rarely provide a good explanation. For example, if something is increasing or decreasing rapidly, try to find other data points that correlate with the change and give more confidence to the analysis.

Plus, always use a pinch of common sense! If all signs point to one way, but the data says otherwise, don’t get too attached to what you measure. Try to find evidence that reconfirms the rational option, and double-check whether the measurements are correct.

Conclusion

It’s an exciting time to onboard as a product manager to a new company or team—if you’re on this journey, congratulations!

In the article above, I detailed the six-step framework I’ve distilled from years of experience joining different companies and teams as a product manager.

The onboarding is not always easy, and product managers want to ensure they invest the first few weeks wisely. The journey includes getting to know the right people, getting familiar with how the business and the team operate, learning what has been done and planned, talking to customers, taking control, and then looking at how things are performing.

And as mentioned before, the learning will never be complete.

As PMs become fluent with the roles and responsibilities, they can start focusing on sharpening their knowledge, learning more about the business, taking a bigger role inside the company, and widening their product management knowledge.

Subscribe now

What’s the best way to structure the product development function inside a company? Squads, long-lived features teams, frontend vs. backend, one team per app, or something else?

While this is a challenging question, the answer would only help us with the way of working. It wouldn’t answer how to distribute a company’s focus, and how to split our business priorities.

Generally, there is no perfect answer on how to scope product teams.

And the boring one is: it depends.

Based on the industry, the product, the customers, the staff, and many other factors. It’s always a custom formula; there is no one size that fits all. Some setups work well for one part of the organization, but not the other part.

In this article, I explore a framework for designing product teams, how that’s similar to making investments, and how it can be translated to deciding on feature priorities.

From empowered teams to investments

Drafting the product organization structure is one thing; creating well-equipped teams for success is another. On the second matter, I very much like Marty Cagan’s empowered product team description and how he defines the responsibilities of roles:

“In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us.”

Of course, there is more to this description, and if you haven’t read Cagan’s article before, I’d highly recommend it.

It takes a lot to create empowered product teams that can operate efficiently with minimum handholding from leadership. But those teams need to be set up first. Kicked off by the leadership who must provide vision, strategy, and frameworks to make that happen.

It wouldn’t be reasonable to assign two teams to a product with only one customer. Or to have one person working on the biggest cash cow functionality, right?

Lackluster team scoping can lead to overinvestment in the wrong priorities and underinvestment in the right ones. To structure teams well, the company vision has to be backed by market knowledge, a list of potential customers, and a demonstrated hunger for a solution.

Even with a good vision, teams can grow a product in different directions—ending up with functionalities that are great for many subsets of customers. But those subsets are not aligned across the whole product.

If the vision from the top is incorrect, individual teams will rarely realize they’re building the wrong thing. How often do teams question their reason for existence?

But then, how to structure product teams as a company to leave room for innovation, maintain popular features, while keeping a healthy level of technical excellence?

There is a way, and the title spoils it all: thinking about product teams as investments.

Long-term, short-term, and the money for food

So how do people structure their investments?

First, people need to run their life: paying rent, buying food, managing utility bills, and taking care of household items like toothpaste and cleaning liquids. Maybe even a car.

Then, a good portion of people has long-term investments: saving for a specific purpose, storing money in low-gain and low-risk assets, as it’s better than just parking the savings in a bank account.

Then again, some people make short-term investments: balancing the sizable risks with potential gains. Ten years ago, this would have meant stocks; today, it’s also crypto and NFTs. (Note: this is not investment advice.)

This splitting makes sense because you’d like to structure wealth so that there is growth potential, but it’s very hard to lose all savings overnight.

And the same approach applies to structuring product teams.

The money for food and basic needs

Teams who provide foundational functionalities to run infrastructure, hosting, and generally enable other teams to deliver value faster. Organizations at scale operate infrastructure, DevOps, or platform product teams. These teams focus on a technical domain, and at most companies, they’re the smallest subset of teams from the list.

Overinvesting in these types of teams can lead to increased efficiencies, but with two caveats:

1. If the problem being worked on by a company is not valuable enough, no matter how good the infrastructure is, the product will eventually fail.

2. Second, improving efficiency is often an exponential curve: putting in an X amount of resources doesn’t result in an X amount of gains.

Long-term, low-risk initiatives

A few cornerstone product features that companies want to continue to capitalize on because they’re driving most of the bottom line. Customers expect them to work well and to gain new functionalities once in a while.

Spotify’s music player, Google’s search, Twitter’s feed, or Jira’s board are a few examples. Here, companies don’t want competitors to catch up just because they were neglecting a feature, so they continue to moderately invest in those.

No one expects colossal growth from these features, but keeping them well-maintained drives further business opportunities.

Short-term, high-risk bets

Additional areas companies are exploring. Areas with great growth potential but also an increased risk. Things that people consider building or already building, but the market/interest is not fully there yet. And for the company, it wouldn’t make sense to bet all of the revenue solely on these.

This group represents another subset of teams, and depending on the lifecycle of the company, could be smaller or bigger than the previous low-risk group.

Startups belong to this high-risk category: they either succeed by finding a product-market fit, just barely stay afloat, or they fail. The risk is high, and the lack of sustainable revenue makes the opportunity window short.

Eventually the a company’s leadership decides how they want to structure the teams based on the three groups above, and what portion of them will be leading bets.

Not focusing enough on innovation can bankrupt any company. And Nokia’s failure to innovate enough in the phone industry before competitors took to the top is well-known.

Betting within product teams

Structuring initiatives like investments can be also translated to how individual product teams prioritize features. Product managers responsible for a single team are equipped with the same set of tools as senior product leaders, just on a smaller scale.

All the functionalities a team is building can be put into one of these boxes:

• Necessary changes: technical work to keep the servers running, reacting to disruptions, enabling scaling, fixings bugs, or upgrading systems. These are the basic needs, so the money for food.

• Long-term & low-risk: adding functionalities to existing features to serve more use cases, optimizing the workflow, improving the user experience, or changing some icons. Small initiatives that keep the core product compelling.

• Short-term & high-risk: brand new solutions that either extend what the whole product is capable of, or increase the number of user segments served. Usually tracked through adoption metrics and whether they’re lifting other KPIs.

The challenge is similar here to scoping multiple product teams.

How can we identify what items belong to which bucket from the three?

Letting short-term bets run long-term without proper measurement can lead to product creep. Having additional functionalities or teams that are costly to maintain and not bringing in the expected returns.

To avoid this, we have to set up rules for graduating bets to long-term initiatives. Defining at which point we should consider a bet as a success and start building on top of it.

Also, what’s the expected return of long-term initiatives? There will be cases when a previous core solution is not performing well anymore, and then we’ll need to choose what to do with that: improve it, replace it, or discontinue it?

And that’s all part of the true cost of a feature.

Conclusion

There is no perfect answer to the ways of structuring product teams, or how to balance different functionalities inside a team.

The best we can do is to think of them as investments:

• money for basic needs,

• long-term & low-risk initiatives,

• and short-term & high-risk bets.

Even if the current organizational setup is not ideal, start somewhere, experiment, take the learnings, keep what’s working well, and gradually improve the other parts.

The conditions, the market, and the opportunities will continuously change.

The best you can do is to adapt to them.

Subscribe now

“Let’s do some user research!”—product managers, designers, and researchers often rely on customer interviews, surveys, and other qualitative user feedback collection methods to understand a new problem area.

Most of these tasks require active and ongoing efforts to get the customers’ feedback. This often means stakeholders start from a blank slate, trying to collect evidence about a suspected problem or a hypothetical solution.

But not all findings need to come from net new efforts. And that’s where the importance of passive product feedback systems comes in, especially for digital products.

Feedback systems consist of processes, functionalities, and tools that were put in place to facilitate the collection of customer insights, compiling them to one central place internally. All are happening without constant or proactive effort from product teams.

Passive product feedback systems are something that companies rarely focus on intentionally and are usually not well documented, but organizations still build components of it over time.

Passive product feedback system components

There are quite a few types of possible system components; below, I look at four examples that I’ve worked with in the past: triggered surveys, feedback buttons, customer-facing stakeholder processes, and event data analytics.

These components can be implemented in a matter of days or weeks, depending on the size of the organization. All have different benefits, but a common theme is that they reinforce each other: they work best together, acting in harmony as part of a coordinated system.

Without further ado, let’s look at the four examples.

Triggered surveys

Triggered surveys are small forms that appear to the user while they’re interacting with a product, usually at the corner of the screen. These surveys are activated by an interaction, a user state change, a completed workflow, or a recurring schedule.

Typical examples include a Net Promoter Score check-in, an app review prompt, an onboarding-completed survey, or a small popup that appears when the user has interacted enough with a new feature to be asked for feedback.

When using these surveys, we don’t have to think about whole product-wide initiatives. Instead, several companies use sub-product questionnaires to measure satisfaction with specific functionalities. One example was Atlassian measuring the new page editing experience in Confluence.

When evaluating the results, it’s not only the scores that matter but also the rate of customers who dismissed our feedback prompt and felt passive or indifferent about answering.

Feedback buttons

In contrast to triggered surveys, feedback buttons do not suddenly pop up for customers; they’re a more permanent part of a product. We can find them in empty areas of an application, with a not-so-attention-seeking design, or often when navigating to the “help” section of an application. What’s also different in their serving is that they’re not dismissable, so even if users don’t have the time to give feedback right now, they can revisit them later if they have some suggestions.

New feature launches inside bigger products typically rely on this method to gather early feedback, provide a direct channel to report bugs, and to generally provide a smooth experience for early adopters.

When designing a feedback button and a feedback form behind it, we should clearly aim to differentiate them from customer service touchpoints, places where our users would turn for immediate help.

Customers should have clear expectations about any feedback button and should not expect any response when submitting something there.

Customer-facing stakeholder processes

One of the most underlooked components of a passive feedback system is designing processes for customer-facing stakeholders. Sales, account managers, onboarding specialists, and support agents all interact with customers. And during the whole client lifecycle, these stakeholders all collect valuable feedback that works best when captured in a central system.

While Google spreadsheets, Jira projects, or specialized product feedback management tools can all fit this purpose, the key is discipline. If there is a clear process on how to capture feedback, all customer-facing stakeholders should be trained to follow that.

And for this feedback to be effective, collecting them is only the first step on the journey. The product organization needs to ensure that feedback is regularly looked at by the right people, triaged, and prioritized according to the potential opportunity.

Event data analytics

The last component in this list is probably the least surprising: event data analytics.

Tracking what functionalities customers use the most often, which are the key user flows (pages or events customers go through), and whether there is an upward or downward trend in utilization.

Event data analytics is used most often with product adoption and success measurement, but it also has a significant role in measuring long-term, continued utilization. Especially when deciding if we have the critical mass to keep up a feature or when thinking about building on top of an existing solution.

This kind of data analysis can also provide us with leading indicators for tracking growth or churn potential related to sub-products.

Are customers using the solution enough to continue paying for it? Is there a correlation between a declining event count and subscription cancellation? If so, does it affect a specific user segment more than others? Could we conclude that our product is not fitting well with that audience? Should we develop better functionalities for that segment, or should we focus on other customers?

These are just some of the questions event data analytics can answer, and without a doubt, this can add a lot to other components in a passive product feedback system.

Why build such a system?

Building a passive product feedback system requires time and effort, and we need a good justification to invest in it. Below, I collected my top three arguments for such a system, plus one potential pitfall to be aware of.

1. The cost of acquiring user feedback is much lower. While passive feedback systems don’t replace all product research efforts, they do help focus the proactive effort where it’s really needed. In addition, not all new features require reinventing the wheel—often, there are perfectly good wheels out there to take inspiration from.

2. Spotting trends outside of our field of vision. We usually pursue specific, well-defined initiatives with active product discovery efforts, which means that some other topics might go under our radar. Passive product feedback systems can help alleviate some of these concerns by providing a more even exposure to user problems.

3. Avoiding scattered or siloed product insights. Even without proper systems in place, organizations already capture a good amount of customer feedback. Without a disciplined process, that information is scattered across our company, sitting with multiple people in multiple different formats/places. Building out components of a passive feedback system can bring those information pieces together in a central place.

Of course, passive product feedback systems are far from perfect.

One obvious pitfall is that these systems might bias us toward well-communicated or more obvious problems. And in the process, we might ignore other opportunities that our users won’t raise, problems that might hide bigger future potential.

So don’t completely rely on inputs from a passive feedback system like this when working on the product strategy. Plus, remember the Henry Ford quote about creativity (that’s probably misquoted):

"If I had asked people what they wanted, they would have said faster horses.”

Conclusion

There are a lot of hidden product insights in any organization. A passive product feedback system can help us surface the customer voices better and provide more channels for this feedback to reach us.

In this article, I covered four components of a passive feedback system that can make product teams more efficient in their product discovery activities. But those will never replace all research efforts, and that’s not the intention.

Product research is still very much needed in topics with low visibility.

As a takeaway, remember that even with well-functioning feedback systems, it’s easy to get biased about apparent improvements. But that doesn’t mean they’d be the most valuable thing to do.

Passive product feedback systems are not enough alone. The resulting insights are only as valuable as the actions and conclusions we take from them.

Subscribe now

What’s the simplest product that first comes to your mind? For me, it’s a weather app. The application that already serves you relevant content without setting anything up. No fiddling with a registration, choosing content preferences, or customizing the app theme.

And a lot of people base many decisions on what’s displayed there: how warm they dress up for the evening, whether they organize that outdoor activity for the next day, or if they should take an umbrella when they leave home.

But to get this effortless experience, there is a ton of complexity behind the scenes: the app needs to correctly determine the location, pull up the data from one of the available sources, and visualize the forecast within a second. And doing these things reliably.

Building simple products is difficult.

In this article, I look at the hallmark of simple but capable products, the indirect cost of complex experiences, and at the end, I present a framework for triaging products based on the effort invested and the user experience they offer.

Tip of an iceberg

Think about a lamp: it’s easy to buy one, plug it into the electrical outlet, and turn it on. Does not seem like a highly complex product in any sense. But what would the same lamp be worth without the intricate power grid system behind it?

Not much.

Many everyday products hide their complexities well. On the surface, we see the user experience and know what the solution is capable of, but we cannot fully understand the work that went into creating the product or what’s powering it.

Just like the tip of an iceberg: what’s visible is less than half of the whole thing.

For digital products, the under-water part is usually the research, the one problem worth building a solution for, securing a budget, recruiting experts, considering many possible alternatives, settling on the final solution, and creating a frictionless experience while making the application reliable and performant on a scale. And if it’s done right, enough customers will be interested in the product to make it a business.

But on the way to building simple products, it’s easy to start cutting too many corners. And we can only play around with the scope, time, or available resources.

What’s an acceptable compromise in terms of user experience, technical excellence, and scalability? Finding the right balance is challenging, and too often we’re encouraged to ship something suboptimal just to get it out the door.

If this happens, let’s remember that every new feature adds to the complexity of the overall product. And if shipping suboptimal solutions become a pattern, we’ll be forced to invest heavily to counterweight that complexity.

So what’s that investment exactly?

The hidden cost of complexity

Imagine writing a five-page essay after every button, checkbox, input field, and other interactive element your product/feature has. How many pages would you end up with?

This exercise roughly illustrates how much communication a product manager and the rest of the organization need to do when documenting, announcing, selling, and supporting a solution.

But that’s not all of it.

The hidden cost also materializes in…

• Hiring for support roles: the number of customer support and training staff, and how deeply technical expertise they need.

• Training investment: training customers and internal colleagues, or educating employees when they join the company.

• Building on top of the solution: the complexity of the user flow, the crowdedness of the interface, architectural complexity, or the always present internal knowledge gap.

• Customer satisfaction: users getting lost in the solution, the feeling that getting things done takes a significant time, and not falling in love with the product—thus considering competitors easier in case there is an attractive offer.

If you use Slack, you might be familiar with how its messaging notifications work. If you mute a channel, you won’t get notifications from that discussion channel. If you activate “do not disturb” or manually pause notifications, all notifications will be muted then.

What sounds like simple logic for the user, ends up being a complex diagram of decision points for the company. Again, we see the tip of the iceberg (customer experience), and everything that’s underneath it (complex but coordinated flow):

In addition, behind-the-scenes complexity can also work against us if we invest in the wrong area.

Imagine search engine “A” that provides 85% relevant results, but it takes two minutes to load those links. Then compare it with search engine “B” which would give 70% relevancy in only two seconds.

As a customer, which search engine would you prefer to use?

The one that invested in the right kind of complexity.

Product complexity matrix

The examples above illustrate that building a simple product is often difficult. Even if the source code is not complex, it takes an effort to figure out the details of an idea and then pressure-test it against everything that can go wrong.

When discussing complexity, we can talk about two types related to product development: the complexity for the company to build the product and the complexity for the user to use the product.

And if we put these factors into a quadrant, we can identify where our products reside:

On the lower left, there are products that are easy to build and easy to use, like a hammer. Products that serve a simple purpose and support 1-2 customer use cases that are used often enough to make it worth building.

On the lower right, we find everyday solutions that are complex to build but easy to use. The more people use it; the more effortless the product should be. Companies want to avoid answering thousands of questions daily if they fail to deliver on their standards.

On the upper right, we can usually observe specialized products geared towards a specific segment of users, intending to serve a wide range of use cases. Airplane cockpits or B2B products are typical examples where there is a high need for training, but also a high need for customization.

And last, on the upper left, we see failed solutions, or at best, temporary ones. If it takes a low effort to build something but a high effort to use it, the product will eventually fail.

Conclusion

Building simple products is difficult.

We must be constantly reminded of the complexity we expose to our users. Plus, building something effortless takes a lot of effort.

If we fail to do this, we might have to pay a higher price in the end.

But not everybody needs to build simple products. Sometimes, our users and the problems we’re solving require complexity, and that’s fine, as long as that complexity is well-managed. Nevertheless, don’t let this be the excuse to give up on simplicity, especially if it’s worth it.

Subscribe now

There are countless memes about the infamous “I’ll put it to the backlog” product manager quote. And for a reason, as it’s a common practice in many places to add new product ideas to the product backlog. What would be wrong with that?

That’s the topic this article is exploring, and how product backlogs become heavy and daunting over time. But what are the ways to avoid the backlog becoming a graveyard of ideas, and restore the important artifact’s lost shine?

What does the backlog contain?

There are always more ideas than the capacity to deliver those. Customers, sales, developers, and other internal stakeholders are constantly coming up with ways how our product could be better.

Should we store those ideas in the backlog? Not really.

Pushing a constant flow of ideas that way will only lead to a very bloated product backlog. One where only the top items matter and all the rest is “something else”. These kinds of backlogs have a bad reputation, and no stakeholders like to work with them.

In addition, the backlog should be a prioritized list, and if anyone can freely add items (or even change the order of those), then the product team’s focus is ultimately lost.

Also, let’s be honest: ideas at the bottom of these backlogs are never addressed. At best, product managers only record suggestions to that place to reassure stakeholders.

If you want to find out whether you’re falling victim to this pattern, go to your backlog right now, and list all the items that haven’t been updated for 3 months. How many items do you see? What if you change it to 6 months? One year?

And these backlogs not only contain product ideas. Technical ideas recorded by the development team are also lining up there: component upgrades, refactors, and other would-be-great-to-do items.

Imagine those backlog items are weights put on a pallet and the product team is required to pull the thing forward. How comfortable would you be putting on one extra weight? What about ten? And who is picking up the falling pieces then?

A different perspective

Another way to approach the subject is to store product and technical ideas separately from the backlog. This way, it’s possible to flexibly triage incoming items in their new place, group recurring ideas together, and avoid comparing suggestions to tasks about to start.

Backlogs should only contain a groomed list of near-term priorities; product and technical items the team consciously prioritized and agreed on.

Don’t get me wrong, I’m not campaigning for a rigid structure where changes are not possible. Agility and adaptation are important, but most teams are not affected by earth-shattering changes every week, so let’s not optimize towards edge cases and extreme flexibility.

Keeping ideas separately has two key benefits.

First, we can design the process of prioritizing ideas freely. We’re not limited by the capabilities of product management tools (Jira, Trello, Azure DevOps…) when grouping or visualizing items.

Second, it should be easily possible to tabulate which ideas are the most demanded and launch product discovery activities in those fields. All without mixing up ideas with other planned items.

Keeping ideas separately is especially useful if we were collecting “official” feature requests in a separate place already. As there is not so much difference between the two, now we can store them together in their new home.

When using this approach in practice, the product manager and the technical lead are shaping the backlog together. In this version, technical and product items are not prioritized separately, the parties agree on one overall priority. Sometimes new functionality developments or user experience improvements are more important, other times refactoring or solution deprecation takes priority.

When this process becomes a habit, the bottom of the backlog doesn’t contain effectively dead ideas, but rather items that’ll be worked on in a few weeks or months.

And plans change, but that’s okay. We should aim for the backlog to reflect the current plan.

The theory in practice

To not just talk about a hypothetical theory, we’re running this approach with my current team for a while. Below, I’ll briefly explain what ceremonies and tools we use for what, but that doesn’t mean this is the only way to do it.

We’re keeping the product backlog in Jira, aligning with the organization’s wider tooling. Product and technical items are mixed but kept in priority order. Stories usually illustrate a bigger effort (often connected to epics), and tasks are smaller chunks of work.

Technical ideas are stored separately, at least somewhat. For practical reasons, we’re using the same Jira product to collect technical ideas, but those items have a different, “Idea” status. While a separation could be better, this made it easy initially to transfer old items to the idea pool.

Product ideas are stored in a specialized tool called Productboard, where we collect customer insights and manage our internal roadmaps. We gather product feedback in the tool and then we group ideas to see what’s the most demanded. Once there is a worthy problem, then it goes through the validation phases. And at the end, the idea graduates from Productboard and becomes a Jira epic with their work items in the backlog.

To ensure new ideas are being looked at, we do a backlog grooming every second week. There, we look at OKRs and the state of current items, then spend most of the time discussing the newly added ideas. For new technical items, we discuss whether it’s an immediate priority or something that we should think about later. And things are rarely an immediate priority, so the theory from above stands: don’t come up with a process for the edge cases.

In addition, every quarter or so we schedule a “big backlog grooming” session where we review the whole backlog and address everything that’s outdated. If the product backlog is kept fairly well, it’s no longer than a 2-hour session. And if something is obsolete, we either delete those items or move them back to an idea. In both cases, it disappears from the backlog.

But again, this is only one way to do it.

Bonus: how others see the topic

I was curious whether ideas are kept separately from the product backlog at other companies, so I asked around. Here are a few takes from the responses:

I allow anyone in the company to add ideas to an Airtable. Complaints/feedback goes into another table once a week, and then I try and match the feedback to the ideas. This is where I go for dry powder when we want to move a metric based on a shift in goals.

—Matt Quinn @ Tanzu Labs

Huge pain point. Backlogs will grow and difficult decisions will have to be made. Most ideas seem like good ones and it's a shame to throw out a good feature, story, spec, or even bug. But if there's little hope in ever being able to justify prioritization of it, it needs to be archived or deleted. This is especially true of empowered product teams where engineers are writing a lot of their own stories, adding their own bugs, etc. There can be too many contributors; what's a product manager to do? This is something I'm facing again, at scale. And I'm asking myself the question, "if I'm going to have to move all this stuff to an archival board at some point, shouldn't I just put it on a separate board to begin with?"

—David Lerner @ Nuts.com

We have a long-term roadmap that allows us to get a big-picture view as to where [ideas] fit while giving us an opportunity to relatively rank their priority beyond evaluating the business impact and engineering effort.

—Larry Chao @ ConstructionBevy

I generally maintain raw and clean backlogs. Raw is just a bunch of ideas/hypotheses, not validated either by quant/quantitative analysis, typically one-pagers. Clean backlogs are where the ideas have been validated and got buy-in from senior execs. Then we start writing the [product requirements document].

—Kali Charan @ Byjus Future School

Subscribe now

The product management profession is getting increasingly popular, and the trend doesn’t seem to slow down. A quick LinkedIn search reveals that multiple thousands of PM jobs are posted to the platform each day.

I mentor aspiring and practicing product managers, and the topic of “how to get into product management” often comes up. People are wondering what’s the best way to start, what are the best resources, or how to draft the application.

In this article, I sum up my advance on getting started on the journey and provide a few useful resources for those who are considering the path.

But first, what is product management?

In my view, good product managers are obsessed with customer problems, and they work to find solutions that solve these problems in a sustainable way. Most product managers have business acumen, high-level technical understanding (doesn’t have to be an SQL guru), very good stakeholder management, and even better adoption skills.

Product managers are informal leaders who influence decisions by bringing structured insights to the eyes of many, often without any direct reports.

Expectations and knowledge

Before getting started with anything else, it’s critical to set correct expectations for the role and seek out information on how product management is done at different companies.

When product management is done right, companies realize the importance of the function and slowly introduce it over time in their organization. And then, the role evolves organically, and supporting departments start to appear to make shipping products easier on a scale.

When the profession is introduced poorly, organizations just re-label existing positions as “product manager” without changing much of the responsibilities. On the surface, it might look like a product manager position, but in the trenches, it won’t feel like one. Be on the lookout for red flags, the role description can already tell a lot.

I found that a good measurement of product organizational maturity is to see what product roles a company has, especially on the leadership level—like Group Product Manager, Head of Product, or Chief Product Officer.

To set correct expectations for the role and the environment in which product managers operate, I often recommend Marty Cagan’s Inspired book as a start. It provides a good overview of everyday concepts, challenges, and a look into the life of modern, empowered product teams.

In addition, Delibr put together a topical guide of the best product management books, a list that often pops up on LinkedIn, and a list from which many books I can recommend.

Let’s keep in mind: product management is art, not science.

I advise aspiring PMs to speak with others in the field to get to know diverse perspectives and see the different ways product teams can work—and there are many good ways to network.

One example is to attend conferences and online meetups, from which there are a lot of free options. Even if there is no happening in your area, reach out to local professionals who you admire, and try to organize something.

Another example is to find a mentor from initiatives like ADPList or The Mentoring Club, where experienced product managers volunteer their time to guide others, and give back to the broader community.

Beyond networking, there is a wide range of product management materials available online: podcasts (Rework, Lenny’s Podcast, Product Thinking, Product School…), publications (like this one!), or courses (Coursera, Udemy, Reforge…). Just find the ones you like or that get recommended by others in your network.

The main goal of setting the right expectations is to ensure you know what product management is, and if you pursue this profession further, you won’t get major surprises about the role and its responsibilities.

And if you’re still excited about the ride, let’s look into the differences in roles and companies.

Identifying the right role

When choosing the right company, people often look at whether their potential candidate is customer- (B2C) or business-focused (B2B).

Business-to-consumer products optimize for scale, put more effort into quality assurance and user experience, regularly rely on quantitative data for decision making, and experiment a lot with smaller changes.

In contrast, business-to-business products optimize for flexibility (covering as many use cases as possible), validate new product ideas without engineering them first, and take more qualitative data into their decision-making.

Jens-Fabian Goetzmann wrote a detailed post about the B2C vs. B2B comparison here.

Both business models have their own perks. And there are also quite a few B2B2C companies like Shopify (online webshops), whose end products are used by consumers, but their direct clients are mostly small businesses.

Personally, I’d advise looking less at whether a company is B2C or B2B, and looking more at how good its product is, how satisfied the customers are, and whether it has a clear future vision and a good company culture.

If unsure, a good question to ask:

Would you use a company’s product if you wouldn’t work for the company?

—supposing that you have some kind of related need.

Another aspect of choosing a company is the size of the organization.

At early-stage companies, product manager roles are often more fluid, the person could be required to draw designs, do some coding, or even try to sell the product to potential customers in their spare time.

The opposite is enterprises. There, the product manager role is well-defined, there is usually a supporting organization (designers, researchers, product marketing…), and there are clear processes in place which were forged over years. In addition, a wrong product decision can’t quickly bankrupt the company.

The choice here is based on personal preference.

Startups are riskier but can have bigger growth potential if the company hits the jackpot. An inexperienced PM might need to come up with a lot of “how to do X” on their own, as the company figures out how to scale, diversify its business, or enter new markets. Also, be on the lookout for too hands-on founders. They should be key partners for early PMs, but shouldn’t dictate everything or micromanage too much.

Bigger companies can be a safer bet and usually, there are more seniority levels among their roles—so it’s easier to join on an associate level. Organizations operating on a scale have forged processes around their product delivery over years, which also means an aspiring candidate has a lot to learn. Although some people prefer a faster pace and might find the operation of bigger corporates too bureaucratic or slow.

When the company size is clear, the industry should be considered next.

I advise mentees to pick an industry that they’re comfortable with. Most people would like to avoid divisive industries like gun, tobacco, or porn. And my general guidance is to choose a company where you can genuinely get excited about the product.

Some industries are more regulated than others, like finance or insurance. So when selecting the company, consider friends’ opinions, talk to PMs from the specific field, and do some research online.

Furthermore, the company culture can greatly affect the decision. Startups.com did a brief comparison of some of the best and worst company cultures out there.

Okay, so then what’s a platform product manager?

It’s great that you’ve asked!

There are several types of product management positions but at small- or medium-sized companies, there won’t be any significant difference in titles. On the other hand, global companies with thousands (B2B) or millions of customers (B2C) often diversify their product roles.

• Generalist PM: an entry role to many people, generalists often work with existing customer-facing products where some technical understanding is required.

• New venture PM: people who mostly focus on launching new products/offerings, building them up from scratch, with good skills in scoping and early validation.

• Platform PM: a heavily technical role that requires a deeper technical understanding, usually working with internal stakeholders as main customers.

• Growth PM: focusing on increasing specific business metrics across the whole solution, often collaborating with multiple other product areas.

David Wang’s recent article provides a deeper look into these roles, although I’d challenge the broader existence of “domain knowledge PMs”—if you’re one of them, let’s get in touch!

Preparing for the application

By the time you get to this point, you should have a good understanding of the product management role, plus its nuances across different industries. And hopefully, you’ve got a diverse look at how it’s done in real life by talking with a few practicing PMs.

While there is no beaten path to product management, most people I know got a product management roles in one of the three ways:

1. Joining a company as an associate/junior PM, or a product analyst.

2. Being recruited to another position (the closer to product the better), then switching to a PM role internally, a few years after.

3. Entering an organization to a product manager role with relevant experience from prior positions (project management, product marketing, former founders…), but none of them called “product manager”.

And some people get into product management without the initial intention of becoming a PM. For example, it’s not rare for engineers, account managers, or other functions working with product to take an internal opportunity and try product management.

The CV and the wording of prior experience can also greatly affect success.

I advise others to carefully review their application materials before applying to product manager roles, especially if it’s a company that they badly want to join.

First, highlight what’s relevant from previous positions: focus on the responsibility, not on the title. While someone might have been an account manager before, they could have a vast experience with customer communication, executing projects on time, stakeholder management, and negotiation—and all are relevant experiences for a PM role.

Second, when drafting the CV, think about the exact, tangible contributions, not what a former job description stated. While it’s essential to create a good understanding of the role, most companies are more curious about an individual’s achievements, not the exact job description they were hired for.

And achieve that by using relevant keywords. For example, if you’ve worked for a B2B software-as-a-service company before, do not forget to add the “SaaS” part.

And a very obvious, but still important factor: do not lie. There is a clear difference between tweaking the wording vs. taking unjustified credit.

Third, think from the recruiter’s perspective. Most companies receive a ton of applications for popular roles, and you want to stand out from the crowd. Think about how to make the CV shine if recruiters only have 2-4 minutes to initially look at the application. What can they get to know about the person? I recommend having a few introductory sentences summing up key parts of the experience and the motivation.

I also get asked if listing certificates or doing courses improves the chances. In my experience, they’re more like a cherry on top. Having specific certificates won’t get you hired for product roles, but they can reaffirm the experience, and more importantly, the motivation to learn.

And if the preparation is successful, the next step is nailing the PM interview.

There is usually a multi-step recruitment process for product roles that may include some homework or trial exercise to be solved. And as with many other positions, the first round is often a pre-screening call with an HR person. The candidate will get to talk to the recruiting manager (senior PM or product director) in the second or third stage.

The interviews themselves aim to test one’s ability to solve problems, highlight specific experiences from prior roles, and see how the candidate would approach various situations. Most interviews begin with the candidate pitching themselves. Here, have a solid pitch that highlights the relevant aspects from prior roles. Keep it relevant, short (around 2 minutes), and professional!

During the interviews, there is a fair share of situational questions, and Product School’s article collected quite a few of them to practice.

If you don’t know something or haven’t faced a particular situation before, it’s better to admit it straight away than to make something up on the spot. Being transparent about the unknowns is an important PM trait.

And beyond preparing for the questions, one should also think through their own questions for the company. Good questions from the candidate show that they’ve prepared and are seriously interested in joining.

Last, remember that interviews are always two-way discussions; there is nothing to be nervous about. The company wants to find a great candidate for its role, and you want to find a great company. Both parties are investing their time in the process and want to ensure there is a good, long-term match.

Plus, getting rejected is not easy, but it’s part of the process.

Often, companies have one open role only but many good candidates. Not being selected for the position doesn’t necessarily translate to not having the skills or experience. Luck, internal backfills, budget cuts, and other organizational factors might also play a part. Even experienced PMs receive rejections.

If this happens, don’t be afraid to ask for feedback, especially if you were invited into parts of the recruitment process.

Some companies are happy to provide additional context about their considerations. And it’s a great opportunity to learn what you excelled in and what you lacked. Even if you were hired, asking for feedback is beneficial.

In any case, I hope this article was a valuable collection of thought nuggets for anyone considering getting into product management. And if you find it useful, please share it with others from your network!

Subscribe now

Last week, Apple held its annual developer conference, WWDC 2022. As usual, the company announced new changes to their operating systems, new tools for developers, and this time, some new hardware upgrades too.

While this series of events was nothing exceptional for Apple, this year’s revelations brought a few surprises. And alongside, clues about what the iPhone maker might be working on next.

If you’ve missed Apple’s keynote, The Verge made a 24-minute supercut.

In this article, I’ll zoom in on some of the announced features and explore what Apple’s motivations might be in pursuing specific areas.

But before that, let’s look at how the company’s focus has changed over time.

Changing company focus

For a long time, Apple was a hardware company. While it made software (most notably its own operating system), the main goal was to sell more hardware. Most of the apps were free and, more importantly, Apple-exclusive.

But in recent years, the trend started to change as the company began investing more in another revenue stream: its software services.

The best indication of how important it has lately become might be 2021’s earnings report, where Apple had $78 billion in revenue for its services business, “now a Fortune 50 company by revenue all on its own” — as CNBC put it.

Hardware is still very profitable, but its overall share is dropping in Apple’s revenue. Laptops, smartphones, and tablets are maturing, and there is just not a big enough market for new devices. In addition, as technology evolves, upgrade cycles also slow down.

If Apple wants to continue its aggressive growth, it must focus on software services or come up with the next big thing. And the WWDC announcements might have helped line the track for the coming train.

Conquering new industries

Apple is a fast follower. The company usually doesn’t launch products that are highly risky or haven’t been validated by the market. Instead, it takes opportunities where there is enough initial interest, refines the idea, and then launches it on a scale.

And 1.2 billion active iPhone units is a massive scale.

Just look at Tile’s example, the Bluetooth location tracker company that was greatly affected by the launch of AirTags, Apple’s competing product. Tile quickly became a niche player in its own market, dominated by the iPhone maker’s scale, technology, and distribution network. Again, 1.2 billion active iPhones.

While Apple didn’t launch any breakthrough products that would replace a key part of its revenue streams in the coming years, it did take on a few new industries.

One of the most interesting moves was the announcement of Apple Pay Later, a direct effort to compete with other buy-now-pay-later (BNPL) providers like Affirm, Klarna, or Afterpay. These services offer users quick, short-term, and most of the time, interest-free loans for online purchases. Users pay the first installment after tapping the “Order” button, and the remaining payments will be collected in weeks/months after.

Again, Apple is dominating with its scale.

The functionality’s integration into Apple Pay means that it’ll become available in 70+ countries, bringing the new payment method front and center to customers.

But the new development also raises two interesting questions:

First, how the new payment scheme would fit Apple’s ethics playbook? According to an SFGate research, 43% of Gen Z users have missed at least one payment when using a BNPL provider. And the company wouldn’t want to be seen as an evil corporation that capitalizes on financially troubled customers.

Second, should neo-banks like Revolut or Wise be worried that the iPhone maker might be going after their business? The company already has some of the financial components; what effort would it be to build the rest?

Another tidbit from WWDC’s announcement was app collaboration features. With this change, users will be able to collaborate with invited contacts in real time. The rollout starts with a few of Apple’s own apps, but developers will also get access to the API to build similar experiences. For example, users can work together on a document or see which browser tab others are viewing in the group.

And hopefully, Apple will clearly indicate when users are interacting with shared tabs. You know, just to avoid seeing the Christmas gifts early.

The company positioned the functionality as a collaboration tool for friends. Still, it’s difficult to ignore how the experience compares to other collaboration suites used in a corporate environment, like Microsoft Office or Google Docs.

Could this be the beginning of a work suite for businesses? Apple devices take a sizable share at many companies, and an expansion to software subscriptions could be a natural extension of its presence.

Although, it’d be a steep hill to climb.

Another product announcement that suits the narrative above was Freeform, the company’s whiteboard collaboration app coming later this year. Sounds familiar? If so, it’s because Apple is stepping on the toes of Miro, Lucidspark, Mural, and other whiteboard collaboration companies.

And again, this new app would be perfect for the corporate environment.

Finding the next big thing

The introduction of the iPhone had an undebatable impact on the phone industry. When Steve Jobs initially introduced the device on stage in 2007, he announced three things: a widescreen iPod with touch controls, a revolutionary mobile phone, and a breakthrough internet communicator. And soon after, he revealed that it was not three devices, but one, and showed the iPhone to the audience for the first time.

Since then, this product line alone has been fueling Apple’s growth engine. Even last year, 14 years after the device’s original introduction, iPhone was the biggest single contributor to Apple’s bottom line—$191.9 billion, to be exact.

But it’s not an infinite source of revenue, and Apple will need to find the next big thing.

One of the biggest surprises WWDC held was the announcement related to CarPlay, the company’s infotainment system. Instead of just a tablet-sized interface for nice functionalities like music or navigation (current experience), the company plans to overtake the whole front panel of compatible cars.

The new version promises deep integration with the vehicle’s real-time systems and the ability to show speed, RPM, fuel level, temperature controls, and other important details.

And now, Apple might be selling the promise here, not yet the final solution. As at the end of the keynote section, the company highlighted the following:

“…vehicles will start to be announced late next year and we can’t wait to show you more further down the road.”

The iPhone maker is long-rumored to be working on its own self-driving car, and separating some user interface elements from the secret project makes a lot of sense.

With the new CarPlay version, the company will be able to test the user experience before launching a real car, collect useful diagnostics data from partner manufacturers, and loop all that feedback into their long-term effort.

The last announced functionality that could be connected to a “big bet” initiative was better text and image recognition capabilities across apps. For example, users will be able to translate instructions from their camera’s viewfinder, pause a video to copy a piece of code, or separate image objects from their background with a simple tap.

While these features are already handy on an iPhone, they could be even more critical if Apple chooses to announce its reported mixed-reality headset. Recognizing text, nearby objects, or even people would be a foundational functionality and would help to blur borders between the environment and the information displayed.

Remember the Minecraft augmented reality demo? And that was 2019.

We’re yet to see how the company would position a mixed-reality device. Would it be a tool for entertainment and playing games, or does Apple imagine being utilized outside of home, at work, or during certain activities?

Augmented reality glasses are nothing new, but in the past, both Google and Microsoft failed to make them mainstream. Would Apple be able to pull the trick?

Conclusion

Technology has never been so accessible to customers as it is today.

But the complexity is also increasing: we’re expecting different things from a smartphone than what we expected 10 years ago. Are we at peak smartphone?

While Apple will surely make improvements to its product lines over the next years, it must come up with the next big thing if it wants to continue its aggressive growth. And the technological advancements the company presented during this year’s WWDC might be some of the groundwork for that.

Subscribe now

In the spring of 2022, I had the opportunity to participate in Reforge’s Scaling Product Delivery program. This article will highlight a few key concepts from the materials, with relevant examples from real-life products.

I’m not aiming to provide full coverage of everything shared in the course but rather a subjective selection of unique concepts and frameworks. Also, a fair bit of warning: it’s not a short article, and it contains several different concepts. If you don’t have a focused 15-20 minutes right now, feel free to bookmark the page for later.

If you do, let’s dive in!

What Reforge and the program are about?

Reforge is a training platform that offers specialized programs for senior marketing, engineering, and product professionals. As part of a yearly subscription, members get live course participation 2-3x a year, access to all program contents, and access to the community. Reforge is somewhat similar to MasterClass, but the company provides more specialized content, the subscription is more expensive, and it includes live sessions.

Their Scaling Product Delivery course focuses on delivering big bet product initiatives. Highlighting some of the systems that make delivering major solutions easier on a scale. Things like how to work together with different stakeholders, or how to keep up an alignment between the team and senior leadership. The program is not about designing a product organization, nor how to ship features faster—although parts of the materials might be useful there.

From hills to climbing the Mount Everest

The course often compares the effort and preparedness of climbing a hill (launching a feature) to climbing Mount Everest (launching a major new solution). Different practice, time, tools, cooperation, and mindset is needed for each. And for the latter (big bet innovations), Reforge offers a four-part structure to guide product and engineering professionals on the journey that consists of the following:

• Building product conviction

• Fabricating a dynamic delivery plan

• Execution and adoption

• Forming a launch strategy

Below, I’ll explore key concepts from each section, with some own commentary and added examples of real-life product events.

But before we do that, it’s important to clarify what we mean by “big bet innovations” first.

These innovations are much bigger than small-scale functionality improvements. They can manifest as new products, new product lines, or major additions to an existing product. Twitter’s spaces, Slack’s huddles, or Amplitude’s customer data platform can be considered as such.

Building product conviction

The first section focuses on discovering and validating opportunities, so building the product conviction. No matter how efficient an engineering organization is, if the initial product idea is flawed, the company’s bottom line will notice it.

While relying on the “product sense” of the founders or early employees might work for a startup (considering it’s fueled by market & customer knowledge), it might not work for a scaled organization. In those places where product decisions are decentralized, companies need an efficient machine that discovers problems and validates solutions.

And validating the best ideas might not always be fast.

As Matt Greenberg, former VP of Engineering at Credit Karma puts it:

“Great teams know that they have to go slow to go fast. The best thing you can do to make products ship faster is to know when to slow down and make sure you get all the right information.”

But before talking about validating the solution, it’s important to know whether we’ve found a vegetable, vitamin, or painkiller-level problem.

What’s that, you ask?

Customers value both vegetables and vitamins, but they don’t address painful or short-term needs. In contrast, painkillers do.

When judging which group our problems belong to, we shouldn’t simply accept our own assumptions, but we should pressure-test them with customers.

And be warned, customers might lie to us.

Not the purposeful, trying-to-cause-harm type of lies, but rather white lies. Our customers want to be nice to us, but that means that they might avoid giving really honest feedback. So even if the proposed idea is the worst, they’ll just agree, stating that it’s “not bad”.

When validating with customers, we shouldn’t just ask whether they like the idea, but we should ask for specific commitments to verify their buy-in.

Reforge recommends asking for a soft commitment first, a light promise if they’ll use the functionality in the future. If they say “yes”, we shouldn’t stop there. Then the request for hard commitment should follow.

We could ask for a monetary commitment from customers (“Can I take your credit card details to deposit some money for the functionality?”), but that’s likely not feasible in most real-life scenarios. So instead, we could ask them to commit X number of hours in the next month. If they agree, then we’d send event invites that they need to accept.

When this exercise is complete, we should count how many committed users we had in the two rounds. If the drop after the first round is significant, it’s likely that our users just wanted to please us, but wouldn’t value the product much.

Real-life example: Tesla is clearly asking for a hard commitment. When ordering their Cybertruck pickup car, the company is asking for a $100 deposit, even though the car’s specifications are not yet finalized. A different angle of this model: this way, customers are providing an interest-free loan to the company.

The last vital takeaway from building the product conviction is that it doesn’t only include the product team.

It’s key to involve all relevant stakeholders early on: engineering, design, commercial departments, and the executive team. The organization needs to be on the same page in terms of what customer value we want to provide, the estimated business impact, and the effort required to build the thing.

And once the initial connection is established, the project stakeholders should maintain the dialogue. As misalignment can cause a late-stage blowup—more on that later.

Fabricating a dynamic delivery plan

After successfully building the product conviction across the main stakeholders, we should develop a flexible delivery plan. One that includes work estimation, sequencing, delegation, and risk mitigation for big bet initiatives.

About estimation: neither overestimation nor underestimation is good.

Overestimation can cause resistance from leadership to approve a project, while underestimation might lead to scope cuts, delays, or an understaffed team trying to achieve the impossible.

To battle this, leaders need a way to forecast and manage the work reliably. And Reforge argues that agile or waterfall are suboptimal approaches for this kind of planning. The first is too flexible and short term, and the second is too rigid and relies on early assumptions being correct.

To ensure a solid foundation for planning, product and engineering people need alignment on the customer problem to be solved, the target user profiles, and key functionalities the solution should contain.

For a successful exercise, the team has to assess the complexity first, and the following four ballpark ranges provide a good starting point to that:

• Straightforward: “we know how to do this”.

• Normal: “we’ve done something like this before”.

• Complicated: “we’ve never done anything similar and don’t know about it”.

• Very complicated: “no one has ever done something like this before”.

Out of these, big bet initiatives typically fall into the last two.

Beyond categorizing the work, there are other complexity factors to be considered: scale, magnitude, stability, and access.

Once we’ve thought about the complexity angle, it’s time to explore work sequencing.

Reforge compares sequencing to cooking instructions when making some delicious food. In order to amaze the audience, the cook would need the right ingredients, the correct amounts, plus the right order of using those to make the dish.

Think about making a hamburger: you don’t want to fry the tomatoes, cut the raw hamburger patty to pieces, or put the sauce on the top of the bun with the seeds, right? If so, why would you make similar mistakes when building a new solution?

Beyond sequencing, setting well-understandable milestones is also important.

We shouldn’t just plan the work and hope that everything will turn out great in the end. Instead, we should continuously monitor the health of the initiative, and whether the milestones are achieved on time. If not, it’s much easier to course-correct earlier in the project.

And when a plan needs adjustment, usually, we can play with three components: scope, time, or resources.

• By changing the scope, we can reduce the number of features included in the first version, reduce the feature complexity (5 colors instead of 20), reduce the quality, or reduce the number of user segments we’re targeting.

• By tweaking the time, we could push the launch date further, if possible. If not, we can still reduce the time spent on quality (fewer tests, messier code…), or shift some of the work to post-launch.

• Last but not least, by adding resources, we can somewhat increase the development speed. But in these cases, remember: 9 women still cannot deliver a baby in 1 month.

Beyond the things above, one more factor can increase complexity: 3rd party partners.

When working with others outside of our organization, we lose some of the process control we have on the inside. The partner might see different priorities or have other processes to tackle the same. In addition, contractual terms, technical limitations, and slow feedback cycles can all play a part in increasing our complexity.

Real-life example: Apple announced in June 2021 that digital ID cards will be available within its Wallet app with the release of iOS 15, an update that rolled out to customers in September 2021. The functionality was heavily off-forecast as it took the company until late March 2022 to announce the first state to utilize digital IDs. And it’s likely that the reliance on US government contributed.

Execution and adoption

When it comes to execution, Reforge compares that activity to driving a speedboat versus commanding a large ship.

Stakeholders who lived through many functionality improvements might be perfectly capable of controlling a speedboat where it’s quick to change directions. But it’s an entirely different game to be in charge of a heavy cruise ship that might need an entire crew to sail to a remote destination.

As with other parts of this framework, constant alignment with relevant teams and senior leadership is important for a smooth ride. The problem, the vision, the chosen direction, and the way to address obstacles all need to be aligned.

One way to view alignment is to study the Vector Math of Teams framework, developed by Hubspot’s Dharmesh Shah and Tesla’s Elon Musk.

According to this idea, people on any given team are vectors that have a magnitude and a direction. If we quantify the impact on a scale of 1 to 10, some people’s vectors might be lower, some might be higher based on their impact.

Not just the magnitude is important, but the direction too.

One nine-value vector pointing in one direction (refine existing product) can be extinguished by another nine-value vector pointing in another direction (build a new product). And then the total sum is zero, and we’ve wasted efforts.

For maximum impact, the vectors should follow each other to build momentum. One practical example is when a team builds a technical enabler solution in the first month; then another team builds on top of that in the second month.

Transitioning from impact to collaboration, Reforge highlights three important gatherings that help to build transparency across the organization. All of them have a different purpose and participants:

• Kick-off meeting: Setting the right context about the problem and the selected solution, communicating the whys—including customer and business value, pricing details, etc. Relevant to all key stakeholders for building a shared vision and understanding.

• Product reviews: Recurring sync between the executive team and core team members building the solution. A no-blame forum for focused feedback, learnings, raising blockers, and getting additional input from the leadership.

• Functional and dependency team touchpoints: A platform for core and other dependent teams to verify the current state, make decisions, communicate those to others, and take the necessary next steps.

By clarifying expectations, these occasions can build a stronger alignment with critical stakeholders, which in turn can help to avoid late-stage blowups.

The last concept in this section I found particularly useful is related to interpreting executive feedback.

Senior leaders give all sorts of feedback during the development lifecycle, but not all of them are instructions to change things. Therefore, when hearing them out, we should isolate the following feedback categories:

• Ideas: “you could consider this”—not an instruction, and the person providing the idea might not even have domain knowledge in the field, they might be simply stating their personal preference.

• Recommendations: “I’d recommend you to do this”—guidance from someone who might have relevant experience in the topic. Can be freely challenged if the team has more insights into the matter or sees something the executive doesn’t.

• Commands: “this is what you need to do”—no room for negotiation; the team needs to follow what was said.

With this approach, even small feedback like “make the button blue” can be easily resolved. We shouldn’t be afraid to ask back whether something was a command or just an idea.

Real-life example: Another case from Apple, its AirPower wireless charger product. The device was announced in September 2017 but it never launched to general public. The device failed to be commercialized due to rumored overheating issues, and then in 2019, Apple official axed their plans to ever release it.

Launch, communication & measurement

Let’s suppose we’ve aligned our organization to deliver a great solution to a relevant problem, and we’ve mostly been on time with the initiative, meeting the major milestones. Finally, as we arrive at the product launch, we’ve reached the top of Mount Everest. But we cannot stop now; we need to get down—and that takes effort too.

Post-launch activities are one of the most underestimated parts of big bet initiatives. It’s not enough to deliver well on a great problem, but we want to be prepared for the moment of launch. And ensure that everything adds to the product value, not substracts.

The first question to address around the topic is how to launch.

There are several different approaches, but in most cases, we want to let users gradually take our product into use, not letting everyone in from the very first minute. This is to avoid unexpected bugs, issues with scalability, or use cases that we haven’t discovered fully.

Reforge breaks down the different launch strategies into three groups:

• Stage by percent of users: The most common method is to let an increasing percentage of customers use the product. For others, it’s not available, or they need to join a waitlist.

• Stage by customer segment: Go live with the new solution for limited customer segments only—restricting it to USA, small businesses, or heavy users. This enables a company to survey the reception of the product on a test group, and if all goes well, scale it to others. This is why Meta/Facebook preferred testing in New Zealand in the past.

• Stage by technology platform: Prioritize the launch on the platform with more users, compatible API functionalities, or where it’s easier to develop the solution. For example, Android dominates in India, so skipping the iOS release is a reasonable choice for applications launching in that market. But often, the choice is whether to launch on the web, iOS, or Android.

From these strategies, companies can also opt to follow multiple at the same time.

Real-life example: Clubhouse, the then-popular live audio app, used two of the three strategies when they launched in March 2020. The product was only available on iOS initially (technology platform), and users needed to sign up for a waitlist first (percent of users) to get access.

After nailing down the launch strategy, companies often find themselves in a tight spot in the weeks leading up to the release. Should they prioritize finishing the last features they’ve planned to include, or focus on increasing the quality, thus eliminating bugs?

To answer this, it’s better to view the remaining work through three lenses: launch blockers, critical items, and non-critical items.

While bugs might be annoying, if a foundational feature needs some extra time (like logging in to the app), it’s clear what the focus should be on—as it’s a launch blocker.

Another common need for big bet initiatives are launch checklists.

As commercial pilots go through a set of standardized checklists as a 200+ passenger airplane takes off, they’re also essential in coordinating product launch events.

These checklists are built by product, engineering, customer support, marketing, and other departments participating in a launch. The goal is to define who does what at a particular time and in what order. It’s easy to recall past events when details of a new product have leaked because a retailer pulled the trigger too early.

And it’s a good reminder that these checklists are not limited to internal stakeholders—external partners, resellers, and agencies might play a part too.

Post-launch measurement is also a key part of the launch strategy, but there is something that flies more often under the radar: disaster planning.

Let’s admit it; new product launches are not always astounding successes.

In the case a new product is not meeting our expectations, there is room to act. But the action is dependent on how sensitive the problem is, and how difficult it is to solve. Reforge presents four “failure modes” in their program, corrective actions that the organization needs to take if sh*t hits the fan.

These modes are:

• Optimize in place: if the flaws are not critical, don’t remove the product, instead fix the issues with additional development work.

• Throttle: minimize the traffic to the solution to limit impact, and gradually roll out the improvements over time.

• Temporary block: if the problem is sensitive and it’s not straightforward to fix it, take down the product temporarily until the new version is out.

• Rollback: when it’s both a highly sensitive problem and a very difficult one to solve, roll back the changes, and consider rethinking the idea.

The course illustrates these options on two axes, severity and solution difficulty:

And the post-launch work should be considered as a part of the product/feature cost.

Real-life example: Slack rolled out a feature in March 2021, enabling anyone to message others as long as the sender knows the email address of the recepient. Then, after customer outcry over privacy concerns and spam, they ended up ditching the feature soon after, triggering a “rollback” situation.

And with the end of this section, we’ve reached the part of a successful product launch. However, we should still ensure that our product provides value over time to customers from this point forward.

Conclusion, remarks

In this article, we’ve covered key concepts from Reforge’s Scaling Product Delivery. We’ve learned the importance of building product conviction, ways to fabricate a dynamic delivery plan, guide the execution, and shape the launch strategy.

But at best, this was only a high-level overview of what the program has to offer, it’s not a complete or detailed guide for any of the concepts—the course has a lot more depth.

One question others ask when I mention Reforge is whether it’s worth the price.

And my answer is: it depends!

If you want to explore a specific topic (like Scaling Product Delivery) in more depth, but not looking for anything else, then the $1.995 yearly fee is way too expensive.

But if you’re looking to level up your knowledge by participating in multiple courses, want to build a wider professional network, and considering using some of the frameworks and materials provided by the company, then it justifies its price.

At last, I want to thank Andy Johns and Matt Greenberg for assembling the course, Louis Bennett for providing great facilitation for the live events, and all the speakers & participants that made the content feel alive!

Also, special thanks to the Reforge team for giving permission to use the images above.

Disclaimer: I was not incentivized by Reforge to write this article, or not affiliated with the company in any way.

Subscribe now

If someone asked you to create an image of “an astronaut lounging in a tropical resort in space in a photorealistic style”, would you be able to do it? And if so, how much time would it take?

Seconds—at least that’s the promise of some new development in the field of AI.

While we’re very far from the artificial intelligence levels of the Terminator movies, machines and AI models have been steadily developing over the past years. In the last two months, both OpenAI and Google announced a new model of theirs, one that can generate photorealistic images based on text prompts.

Say hello to DALL-E 2 and Imagen!

The technology is early, and the access is very limited, but it has great potential for the future. And as with any advancements, these models also raise a few questions:

What are the limitations of this new piece of technology? What products could take advantage of the generated images? And how could we prevent misuse?

The way it works, differences & limitations

Both AI models work in a similar way: first, they take the user-inputted text and generate a relatively small image (64 x 64 pixels). Then, the image gets processed over and over to enhance it with additional details (“super-resolution diffusion”), resulting in the final image (1024 x 1024 pixels).

Yes, something like those crime series where they reconstruct a face or a number plate out of a blurry security video. But that part in those series remains science fiction, as it’s simply impossible to recreate the real face out of 4 pixels only.

To create a random face that has no connection to the original? Yes, that’d be possible!

In order to generate the images, both AI models need to correctly recognize the prompted text first and details such as relative word positioning or adjectives.

Do you want to see a “blue apple on top of a red book”? Then these models need to recognize what’s blue and red, what items they’re linked to, and what’s on top of what.

This exercise is not an easy feat, and Google seems to have an advantage here if we’re to believe their research paper. They state that they’re better at recognizing the context between words, and based on the published samples, they’re seemingly better at rendering text.

And while the two solutions are similar in concept, they have slightly different capabilities.

DALL-E 2 is not only capable of generating images from text prompts, but also able to add or remove elements from an image (respecting lightning and shadows), or create different variations inspired by the original picture.

In contrast, Google’s Imagen solution focuses on creating photorealistic images out of the text prompts instead of image manipulation. The company has years of experience in machine language understanding with wide-scale products like Google Assistant, so an advantage here is expected.

Both AI models look promising based on the samples, but it’s also clear that the technology is early—it’s easy to spot blurry parts or abnormal objects on the rendered images.

Productizing the AI models

Today, both of these AI models are primarily available to researchers, hinting that the technology is not yet ready for a wide-scale utilization. Although in the future, we might see a couple of products leveraging the advancements.

In the consumer space, it’s easy to imagine applications using this that are working with user-generated content or managing online identities. A new way to create online avatars, personalizing content in entertainment or gaming, customized animations, or trying to make a living out of generating non-fungible tokens (NFTs).

And regarding the last point, OpenAI clearly thought people would want to use the technology to sell NFTs, as they’ve worded the following part to their content policy:

You may not license, sell, trade, or otherwise transact on these image generations in any form, including through related assets such as NFTs.

On top of the consumer use cases, businesses and creators can also see a huge potential in the new developments. Imagine photo editing tools getting a “prompt to generate image” functionality, or agencies creating even more attention-grabbing creatives for advertising.

Two important factors need to improve before we see these AI models in real products.

Scaling: For this to appear in various applications, the AI model should be able to do many parallel renditions in a given timeframe, and those need to be fast. Users won’t wait minutes or hours in most cases to get the results.

Reliability: Not just increased confidence that the technology will provide the expected results, but that it’ll output images that are safe to use, especially for brands whose audience include minors.

A few open questions that need an answer

As with every new development, these AI models also raise a few important questions.

First, who owns the content rights for the generated images? Technically, users provide the input to the AI model to generate the work, but the AI is doing the heavy lifting. For example, how much difference is needed to recognize a generated image as unique if it was created by tweaking an original artwork?

Second, as explored above, how can we prevent misuse? Or, should the companies behind the models provide safeguards at all to prevent people from generating harmful, illegal, or adult content? If so, what should be the exact rules, and how can providers ensure they’re kept?

Third, our world is full of known brands and people. How should these models respond when users ask them to generate the face of a public figure, a well-known cartoon character, or a widely recognized brand? Would inputting “Michael Jordan drinking Coke while losing a basketball match against Bugs Bunny” work?

These questions will be important to answer before the technology is released to the wider public to take advantage of.

What to expect in the next years

As discussed before, the technology is still relatively new, so it’s likely years away until we see it being utilized in real products. But when we do, we might see different versions of it fine-tuned for specific applications.

One that can draw Disney characters only, one that is limited to painting in Van Gogh’s style, and maybe another one that only creates Garfield comics.

But in most cases, it’ll be a delighter functionality, not a critical one to have.

Subscribe now

In April 2022, Netflix announced losing 200.000 subscribers during its quarterly earnings call, the first loss in 10 years. The news sent its stock and valuation plummeting, losing 35% the next day (equaling $50 billion), and even more since then. After these events, the company also announced organizational restructuring, laying off more than 150 employees in the process.

What happened to Netflix’s growth engine? Is the market getting too saturated and the competition too fierce? Do people use the service less often? And what lesson does it offer to others?

From DVDs to streaming

Before looking into the current situation, it’s useful to recap where Netflix is coming from and how it evolved over the decades.

Netflix started as a DVD mail rental company in 1997. The company successfully capitalized on technological innovation, as DVDs were just introduced in the same year in the US. This proved to be quite an advantage, as the VHS tapes were more costly to handle and more fragile.

Around 2000, the company changed to a flat-fee subscription model instead of a per-item renting fee, offering unlimited rentals without due dates or shipping fees. It reached its first profitable year in 2003 ($6.5 million), and one million shipped DVDs per day by 2005. Even back then, it had already started to focus on investing heavily in its recommendation algorithm.

Netflix’s streaming service launched in 2007 with 1.000 titles, which grew to 11.000 by 2011. That was the same year when the company spun off its DVD business from its main platform. The DVD rental business still generated $200 million in revenue last year, although the website currently shows a 404 page. Starting in 2013, Netflix started focusing on original content production, which made up 40% of all content in its US library in 2021.

In recent years, the streaming giant experimented with various content formats (i.e., shorts, interactive shows), and just last year, it announced plans to focus on gaming. At the time of writing, there were around 20 gaming apps made available by Netflix on Apple’s App Store.

Declining growth and the competition

While Netflix has the biggest audience among the various streaming providers (221.6 million paying subscribers in Q1 2022), it’s surely not alone on the market. Quite a few competitors have launched with similar business models not long after Netflix did, but they were not able to get ahead of the streaming giant. Amazon Prime Video is the only player that got close with its 180 million-plus subscribers.

The real threat to Netflix’s growth materialized when content owners started launching their own streaming services with the introduction of Disney+ and HBO Max. Both services launched around the same time (end of 2019, beginning of 2020) and represented a significantly different business model.

The difference? The two companies entering the space didn’t need to spend big money on licensing fees, as they already owned most of the content. Not only that, but they were also content partners to Netflix (and they still are), negotiating licensing conditions and costs.

Resulting in a situation where Netflix needed to partner up with its competitors.

While Netflix’s growth has flattened in the past quarters and expects to lose another two million customers in Q2 2022, Disney+ and HBO Max are growing solidly. Both services added 70-100 million new subscribers in the last 2 years, and they expect to grow further—although their growth rate will likely slow down.

Beyond the market saturation and users increasingly using multiple streaming providers, macro factors also contributed to Netflix’s valuation drop.

First, many tech companies are still overvalued. In Netflix’s case, the sobering news of subscriber loss might have triggered a value normalization, which could have contributed to the overall dip.

Second, global events such as Russia’s invasion of Ukraine also played a part. Netflix was present in both countries (the Ukrainian version launched in 2021), but the company suspended its services in Russia at the beginning of March 2022, locking out roughly 1 million subscribers.

Lastly, it’s good to keep in mind that Netflix has bumped its subscription prices up repeatedly throughout the years. In the US, the “standard” subscription was $11 in Oct 2017, and it costs $15.49 today—making it one of the most expensive streaming providers without a live TV offering.

Lessons for business & product management

Even with the latest news, Netflix has more than a healthy business: it’s available in 190+ countries, with 200M+ paying customers, and has close to $30 billion in yearly revenue. That’s no small feat.

With being said that, there are some important learnings from what the company has done and the opportunities it has missed:

• A core experience that’s better than the competition: Over the years, Netflix has invested heavily in ensuring the core product experience is smooth and interested users can become paying customers in minutes. In addition, it’s fine-tuned its recommendation algorithm, introduced a discovery feed, and done a significant amount of A/B tests for further optimizations. The company didn’t forget about the importance of the core experience, and it did a lot to be better than the competition.

• A hard-to-copy advantage is not impossible to copy: Netflix’s business model, content offering, brand, and technology were once considered to be a high fence to climb. New players were able to win sizable chucks of the streaming market by having a strong brand and content offering, and developing the rest. Netflix’s former product VP, Gibson Biddle, summarized the company’s hard-to-copy attributes a few months before Disney+ and HBO Max launched.

• Underutilized benefits of scale: Unlike other big tech companies, Netflix didn’t experiment enough with new product lines that could have benefited from their already great presence. In contrast, Facebook launched a marketplace product at 1.5 billion monthly active users, and Apple introduced AirTags with 1.2 billion iPhone devices out in the wild. In both cases, the new products quickly won over the competition, and the companies’ already broad reach made a significant contribution to that.

So has Netflix really peaked? What’s the next big bet for the company?

In short, we’ll have to wait and see.

For one, online streaming is here to stay, so Netflix’s business is not likely to change radically in the next few years—but that alone does not make the stock quickly rebound. Beyond that, the company is pursuing gaming as the “new way to experience entertainment on mobile”, and it has recently launched an experiment with live TV.