In today’s issue I will share a way of thinking about roadmaps that’s proven most robust in my product management practice.

There’s no shortage of model frameworks to build a roadmap. But as the saying goes: “All models are wrong, some are useful” [​George Box​].

I’ll want to share with you an approach to thinking about roadmaps that has been useful in my product practice.

Some would say it’s boring because it relies on some [rather basic] math. I would call it “grounded” instead. And that’s exactly what makes it so powerful.

First, three important statements before we begin:

• Roadmap is a portfolio of bets

• Each bet has an expected value

• Most bets will fail, i.e. their EV will be 0 or even negative

It’s best to think about roadmaps in purely economic terms. Your company has a budget which it can invest in a portfolio of projects. The return from some of those projects will exceed the investment greatly. Some will break even, but most will lose money. And that is absolutely okay, as long as the combined return from those bets is positive.

Venture Capital firms operate under the same principle. And if you look at a typical fund, you will notice how VC investments have a power law distribution of returns:

• A handful of startups (typically a single-digit percentage) generate 5x - 100x returns

• 20-30% return 1-2x or break even

• 70% or more result in a loss

The graph below illustrates this very well. [Source: ​https://www.linkedin.com/pulse/vc-power-law-james-church/​]

Successful VC firms are sophisticated investors who figured out the most important truth about investing in technology: each project has a limited upside and an unlimited downside:

• The upside is limited by market size, competition, efficiency of distribution, execution, and other factors.

• The downside is unlimited because you can invest resources indefinitely [money, effort, etc].

Therefore, VCs construct their investment portfolios to limit the downside and apply the principle of asymmetric payoff: the likelihood of a positive return from the combined portfolio must be higher than the likelihood of losing money. As long as 1-2% of bets return at least 10x of their investments, the rest of the bets can lose money. Mathematically, it’s still a win.

Start thinking in portfolios

The same logic applies to roadmaps. Individually, most initiatives will never reach their goals. But collectively, they will achieve a good ROI.

The most important product management job when building and managing a roadmap is to limit the downside.

Mathematically, this means:

• Making sure that the Expected Value of each roadmap item is above 0 at all times

• Stopping the projects whose EV has turned 0 or became negative

Here, Expected Value = Impact x Probability of Impact

Some examples

This is not a new approach. Look at the most popular roadmap prioritization framework: Reach, Impact, Confidence, Effort (RICE). What you’re really trying to estimate here is the Expected Value of a product initiative by using proxy metrics. And this is where it gets complicated.

In the real world, there will be many input variables that influence the EV of a roadmap item. And most of those variables are non-linear, i.e. they are probabilistic functions of some other variables.

Consider the Effort variable in the RICE framework. Effort depends on how skilled the engineering team is at solving a technical problem. But that “skill” is not a constant. If the team of engineers doesn’t have any attrition, their skill improves with time. If a new engineer joins mid-development, the average level of skill at the team decreases because this new team member needs onboarding.

A myriad of other variables fluctuate as well: market dynamics, regulation, consumer behavior patterns, trends, and company strategy — all those things change the EV of a roadmap item.

This means that the Expected Value of a roadmap item can become negative at any time. Even after the development has already started.

So, how do you manage a roadmap then?

1. Accept that a double-digit % of your roadmap will have a negative or 0 Expected Value. This number will typically be between 50% and 70%.

2. Define leading indicators which you can track to foresee the decline to 0.

3. Have a set of stopping criteria for each initiative, i.e. the leading indicator thresholds which will stop the project.

Liked what you read? Get in on future posts here:

Subscribe now

Seriously, there are better things to do in life 😅

Some topics in product are fun, though. So, I’m launching a new thing called Product Science.

Check it here: https://productscience.academy

What gives?

I feel that product management has largely lost its way. It’s crumbling under the weight of hand-wavy frameworks that only help the people who sell them.

Product Science is my tiny attempt to right this wrong and re-focus the conversation on the aspects of Product that are grounded in math, psychology, social sciences.

The result is a multi-part, evergreen email course. I write each Part once, continuously refine it based on feedback, and then release newer versions and follow-on courses.

This way, I get to share my knowledge and ideas without the pressure to pump out content on a schedule.

The best thing? It’s free. I have no intention of monetizing this or any future content directly.

Seriously, go check it out.

The first part is called Probabilistic Product Management. In it, I talk about:

• Why products fail and how to deal with it

• How to apply probabilistic thinking to roadmaps

• Decreasing strategy risk via discovery and user research

• Making better bets with probabilistic strategy

If all of that sounds interesting, go check it out.

PS

While I won’t be sun-setting The Product Thinker any time soon, most of my attention will focus on Product Science from now on.

- Ev

You probably think, "OMG! Why would you do such a thing?! (Can I get their email?)." Here's why: the CTO wanted to build a 100% in-person team. And me... I'm in the "I'll dial in from the Airbnb" camp 🏝️

I'm not here to explain why remote work is awesome, though. Instead, I want to help you figure out whether it's appropriate for your company to take the risks associated with building a 100% remote culture — or not.

At startups, every decision carries a downside risk. Especially in the early stages, a startup's success is defined by the founders' ability to recognize, manage, and mitigate different types of risk. 

Unsurprisingly, the skills required to build a thriving remote culture differ from those needed to create an in-person culture. If a founder without the requisite expertise tries to build a remote culture, they layer on an additional level of risk which they can't see, let alone manage. This is a great way to dig your company into a deep grave.

So, what are those skills and risks? Let's dive in.

Cross-cultural communication

When you're building a distributed organization, you're inevitably hiring across cultures. 

Quickly, you end up in a situation where talented people run into the pitfalls of cross-cultural conflicts. The most insidious side-effect of them is a loss of trust. 

"You're not speaking up enough."

"She's always late!"

"He's not proactive and only does what he's told."

"She's not direct enough in her feedback, making collaboration impossible."

"He's too direct. This is so rude, and I dread working with him."

Those are just some of the (quite real) phrases your future colleagues will use to describe their peers. In most cases, the root cause of each is a breakdown in cross-cultural communication across one of the 8 cultural dimensions identified by Eryn Meyer.

A founder skilled at building remote cultures will recognize this and help the team overcome the barriers. They could do that in one of three ways:

• through cross-cultural coaching and conflict resolution

• by hiring an external coach

• by adjusting the hiring practices and screening for the candidate's ability to work cross-culturally.

Knowledge management and transfer

Every team has two types of knowledge: tacit and explicit. Tacit is the informal knowledge we pick up in water cooler conversations with colleagues, quick meetings, or workshops. 

Tacit knowledge is implicit, and it's often not very well structured. But it's often exceptionally timely and, therefore, vital for the health and function of a company. 

Explicit knowledge, on the other hand, is codified. It's your Notion space, your API manual, the explanations in your Git pull requests, and your Jira (or Coda) tickets.

Due to how easy it is to create and share tacit knowledge, many fast-moving in-person Seed and Series A startups have somewhat limited and outdated documentation. Truth be told, they probably don't need it.

In contrast, 100% remote startups — especially those with employees across time zones — can't rely on tacit knowledge. Gone are the unstructured encounters with peers and quick "let's grab a coffee and do a walking meeting" conversations. Nada.

Employees have to write things down. They must learn to tell stories, convince, and explain via clear, structured written language. That's hard even for native speakers of English, let alone folks for whom English is a second or third language.

This means that the founders who aspire to run a 100% remote team must think about

• how to hire engineers for communication, not just their technical ability

• how to help the team improve written communication skills

• how to build a no-meetings culture of asynchronous communication (instead of requiring meeting notes after every call — what a waste of time)

Morale & Rapport

Few of us can instantly connect with another human via Zoom. Our noisy mics and grainy videos make it hard to build rapport and see our colleagues as living souls instead of task-completing machines. 

It's not impossible, though. Building a team-level rapport in a fully remote, geographically dispersed organization with diverse cultures requires a deep understanding of how to work with humans, social finesse, and how humans work. (And no, not everything can be solved through Radical Candor because that book applies best to cultures of Anglo-Saxon origin. To others, not so much.)

Employee development

Helping people improve is an arduous task in in-person cultures. It sometimes feels outright impossible in fully remote organizations.

Robust employee development programs rely on a strong rapport between employees and their managers and a deep understanding of individual motivations, goals, strengths, and weaknesses.

In other words, employee development is highly contextual. Building such a level of interpersonal and managerial context in remote-first organizations requires a systematic approach that leaders who are used to in-person cultures often don't have. 

Hiring and bias

Hiring across cultures? Welcome to a whole new level of complexity in fairness and evaluation: 

Does this candidate have poor communication skills? Or do they simply follow a principles-first pattern in structuring their answer?

Note: principles-first cultures practice deductive reasoning. One must develop the theory or complex concept before presenting facts or opinions. Begin all messages by building a theoretical argument before moving on to a conclusion. The conceptual principles underlying each situation are valued.

Is this candidate insincere and lying about their experience? Or do they come from a culture where good communication is sophisticated and layered, so you're expected to read between the lines?

Note: In high-context cultures, good communication is sophisticated, nuanced, and layered. Messages are both spoken and read between the lines. Ideas are often implied and not plainly explained.

None of this is easy. Remote-first cultures are not for everyone, and depending on your level of skill and comfort as a founder, your mileage may vary.

As long as you can manage the risks of remote-first work, you can reap the benefits of it, too.

Want to work with me?

If you’re a founder of a late-Seed or early Series A startup and need help with:

• accelerating your product execution and the search for PMF

• setting up product discovery

• building a product team

Then let’s chat.

🚀 My calendar is open: https://calendly.com/evgeny-lazarenko/founder-product-coaching

Alternatively, you can hit me up on LinkedIn.

"Everybody worships. The only choice we get is what to worship. And the compelling reason for maybe choosing some sort of god or spiritual-type thing to worship — be it JC or Allah, be it YHWH or the Wiccan Mother Goddess, or the Four Noble Truths, or some inviolable set of ethical principles — is that pretty much anything else you worship will eat you alive." — David Foster Wallace

Every profession has heroes — the people who reached the top in their craft owing to a combination of wits and luck. Out of the depths of their hard-earned wisdom often comes the desire to teach and level up others. 

In product management, Lenny Rachitsky, Shreyas Doshi, and Marty Cagan are such people. They have made it their mission to help product managers level up to the Top 1%. According to them, a distinct combination of skills, habits, and practices sets apart the cream of the crop of PMs. You, too, can build those skills, develop habits, and learn the practices. 

It's a fine message because career and financial results will follow with enough effort. It's good to remember, however, that the pursuit of professional excellence doesn't guarantee happiness. Often, it's the contrary: a single-minded focus on professional mastery means tying your self-worth to an external measure of success.

I know that because I've been there. For years I've been so obsessed with professional growth that I would start and finish my waking hours learning product management instead of spending time with the dearest people in my life. It made me more than a decent PM, but it also made me miserable. I couldn't even hold a conversation that didn't revolve around work.

How exactly did we end up here?

Many PMs I know started doing it as a stepping stone toward something else. Some wanted more business impact, and software engineering didn't allow that. Others were like me and aspired to become founders. To them, Product was the best way to learn the ropes and to have a go at end-to-end influence on the business. 

In all cases, a special something made us move into Product. However, as we grew in skills and ranks, our professional journeys took a more traditional turn: to get promoted, we needed to build strategy skills, growth skills, and technical skills. We mastered stakeholder management and learned to communicate under pressure. 

The further we went along in our product careers, the further we moved away from why we started those careers in the first place. The abundance of accessible professional education gave us easy goals: take this course, sign up for that newsletter, and definitely earn this certification. The cycle of learning, doing, learning, doing, learning, doing was made so easy that we forgot to ask: Learning — what for? Doing — what for? 

Somehow, we forgot the intrinsic goals that brought us into Product and swapped them for extrinsic goals of beefing up our expertise and climbing the career ladder.

Of course, product managers aren't the only ones suffering from this. Hoards of people from almost every professional field are stuck in temporary careers that became permanent. Unsurprisingly, many are secretly miserable in their jobs. Multiple studies of motivation and wellness show that people who pursue goals imposed by social or professional expectations have low well-being and life satisfaction. This is true for all goals: short, medium, and long-term. 

In other words: if you're honing your skills on an auto-pilot because that's expected of you as a top performer, you may not be doing so well — regardless of the size of your paycheck.

There's a way to change this

Remember how you used to believe that anything in life was possible? Then you started making choices and narrowing down options, resulting in a decent life, but probably not what you were hoping for.

This happened because when making compromises, you might have focused on something that was expected of you over something else that was important to you. You then justified that and adopted those goals as your own. And here you are.

But you're not stuck, and there's a way to switch to another track. Doing that is as simple as getting back to your core values. Many techniques exist for that, but I especially like the one from a book called Designing Your Life (see below).

Creating your new life plans

Your task is to create three alternative life plans for the next five years. Each of those plans must be progressively divergent from your current path:

Plan One must focus on your current life plan. It's good to bring in bold ideas and goals you may already have. 

Plan Two must explore your life if Plan One is not an option. Imagine that the thing you do now simply doesn't exist anymore. If you're a product manager, assume that ChatGPT is doing your job and tech companies don't need PMs anymore. You can't make a living in your old field of work and industry. What's your new domain? What does your life look like?

Plan Three is the wildest. In it, you must describe the life you could live if money or status weren't a problem. If you knew you could support yourself regardless of what you do — what would you do? What would your life be like?

I made a Google Doc template for this exercise: Three Life Plans - Template.

If that's too much work, you can do a simple freewriting exercise to unlock your thought process. Try this reflection prompt: If you couldn't do your job anymore, what would you do instead?

Subscribe now

Image credit: absurd.design

Research reference: Self-Determination Theory: Basic Psychological Needs in Motivation, Development, and Wellness; Richard M. Ryan and Edward L. Deci

“Damn, look at this! We’re in the wrong business”, said my colleague. 

We were peering over one of our customer accounts. He ran an e-commerce business as a one-man show and made over $6M a year in revenue with at least a 50% margin. He was selling slippers. Cheap, mass-produced rubber slippers. Shipping them across the US, he made one heck of a living.

At the time, I worked at a B2B SaaS company that built inventory management software for e-commerce SMEs. Most of our clients were growing successful cashflow-positive lifestyle businesses, and being a product manager, I spoke with hundreds of them. Those entrepreneurs usually started small but eventually grew their basic e-commerce shops into multi-million revenue machines. Their success was astounding. And yet, I couldn’t find inspiration in their journeys.

I was captivated by tech startups and wanted to build my own. E-commerce, consulting, teaching — none of them felt like interesting businesses to me, no matter the degree of independence and happiness their founders found in life. I wanted to either go big and build a multi-billion dollar business or go home. And home I went, again and again. 

It took me years to realize that you don’t have to go big. The world is full of small yet exciting problems, and solving them could earn me a living. Those problems flew under my radar because no matter how well I could solve them, those solutions would never reach venture scale.

If you don’t know what venture scale means, here’s a rule of thumb: your startup must have the potential to reach annual recurring revenue of ~$100M to ~$150M within 7-10 years of operation. Then and only then your company becomes an attractive investment for a typical technology VC firm. (The exact math behind these numbers is irrelevant to this post, so I’m omitting it in favor of a simplified rule.)

Working backward, it’s clear that several things must hold for a company to reach such a level of revenue:

1. They must find a big problem that many businesses or consumers have, thus opening an addressable market in the billions and an obtainable market in the hundreds of millions

2. They must be extremely good at solving that problem — which means having the top-notch expensive talent

3. They must be exceptional in acquiring customers for their solution — at scale

And this is where things start to break. Economically, most businesses can’t get there:

• Most problems are not worth hundreds of millions

• “Good enough” solutions are often sufficient

• Excellent acquisition only matters at scale, and there’s often no scale to speak of

A vivid example of this is Morning Brew. Despite having significant traction, Brew’s founder Alex Lieberman didn’t raise money from traditional tech VCs. In his fundraising journey, he learned that media companies are inherently not venture-scale:

“Venture capitalists have an expectation that a single investment will pay back their entire fund. And to pay back your entire fund the investment has to go 10 -  20 - 50x. 

But when we’re looking at the trajectory of a healthy media company, a media company doesn’t grow in such an aggressive exponential manner.”

If most businesses aren’t venture scale, and 90% of venture-backed startups die within the first few years, you’re better off running a conventional business.

In essence, you have to turn the standard notion on its head: instead of thinking big and going bold, you must think small and bootstrap. But how?

Look within to find your best idea

After years of dreaming about building a scaled tech startup that would eventually have a bazillion-dollar exit, I gave up. While it sounded nice in theory, the odds of success were low. This wasn’t worth my time any longer.

That realization helped me to explore less glamorous ideas. Eventually, I focused on a problem I care about deeply: helping people move abroad and build better lives.

In retrospect, I arrived at this problem organically: I’ve been coaching friends who wanted to leave their countries and explore living overseas for years. After all, as a lifelong expat and a military kid, I’ve been doing that for most of my 36 years on Earth: moving around. The secret to finding that idea was to look inside, reflect on all the things that interested me, and match them with actions I took to help others.

I’m on the journey to build the first potential solution to that problem: a cohort-based course that teaches mid-career tech professionals to Launch a global career in technology. As a product manager, I’m learning a ton from this. Excited to share more later! 🚀

💡 To find your idea, try this exercise: Look at the past ten years of your life and write down problems that you have consistently solved for others — even if you weren’t paid to do that.

Tip: Don’t worry about things like competitive advantage or defensibility. Just pick a problem you enjoyed solving before.

After that, make a list of possible solutions and pick one. Your process will follow the double-diamond framework:

Once you find the problem you want to solve and the solution to test, the hardest part is done. Next is to create the first iteration of that solution. But that is another story :)

In today’s issue: a quick (and speculative) take on why Elon Musk’s idea of the X superapp has legs.

Elon Musk’s words raised eyebrows when he shared a plan to turn Twitter into a foundation for his upcoming super app called X. US tech media responded with skepticism, arguing that the Asia-native super app strategy doesn’t fit the existing behavioral patterns of North American users.

The problem is, such thinking assumes Musk is betting on building a product for North American users. My contrarian take is that it’s not the case. Let’s break down why this might be so.

Demographics & Growth

First off, demographics. As of 2022, over 30% of Twitter users are based in the fast growing internet markets of Southeast Asia and Latin America. There, the comparatively young internet natives use superapps daily.  (Source: Statista) The precedents set by Grab, GoJek  Rappi and others proves that the superapp model works in those regions and could support large and profitable consumer platforms.

Speaking of growth dynamics, Twitter’s user base in Asia Pacific and Latin America grew 3% and 1% respectively in 2022 — compared to a -0.5% contraction in North America (source). The biggest takeaway from this is that Twitter is growing the fastest in regions where it could earn the lowest ad revenue per user. Considering the economic and privacy headwinds, effective monetization of this user base is only possible by tapping into direct P2P transactions and value creation, such as social commerce and payments.

User Generated Content

Leveraging Twitter, X will have what Grab and others were never able to create: the social layer powered by user-generated content. UGC offers one of the best ways to grow engagement within the product, thus creating growth loops that other super apps have to fuel through other means.

The best industry example of this is WeChat, and the second best is the Facebook Blue App which used the superapp patterns to introduce elements of social commerce and payments.

Here, Twitter’s performance in APAC and LatAm is also superior. For instance, its monthly time on site in Indonesia was 37% above the average time on site worldwide (source).

Outlier behaviors & experimental features 

Some outlier behaviors of Twitter users already follow patterns that could be translated into a superapp design. Many of those behaviors are supported by the experimental features that Twitter rolled out over the past two years. What’s even more interesting is how widespread those behaviors and features are among the crypto-native crowd.

For instance, ENS domains have become extremely popular on Twitter. Used instead of names, they signal that — among many other things — a user accepts crypto. This behavior indicates a potential opportunity for crypto remittances embedded directly into Twitter. Twitter tips could provide infrastructure on-ramps for that.

Will X become a web3 superapp?

Earlier this year I made a case for web3 superapps, and my speculative hunch is that Twitter-powered X very well might become one of the most exciting consumer web3 projects of the decade. Musk is crazy enough to bet on consumer crypto, and if we look beyond the facade of weirdness, his ideas for Twitter — at least those discussed publicly — all point toward it becoming a massive ecosystem product. 

In today’s issue: OKRs, the nemesis of product teams in early stage startups.

OKRs and pre-Product Market Fit startups don’t mix. They also don’t work for 0-to-1 initiatives in big companies. To understand why, let’s start with a bit of history. 

The genesis of OKRs is in Peter Drucker’s framework called Management by Objectives. The idea behind MBO is simple: teams must define goals they need to hit, and then create roadmaps for reaching them. It sounds reasonable, at least if the goals are deterministic, but in reality they are not.

Unlike MBOs, OKRs are more specific as they introduce measurable Key Results into the planning equation and — at least in theory — that helps teams to align on what really matters in the business. Unfortunately, in 0-to-1 products, “what matters” evolves faster than OKRs can accommodate.

Objectives and Key results is an idealistic framework that makes two assumptions:

• First, it assumes that your company or group has a working strategy, 

• Second, it assumes that enough time (a.k.a. funding) is available to nail the OKR planning process and see tangible results. 

Both of these assumptions are true for established revenue-generating products and are false for pre-Product Market Fit initiatives.

OKRs require a defined strategy 

If you work in a startup environment and build 0-to-1 products, you must make snap decisions and pivot rapidly, or you will run out of funding. In fact, the primary existential objective of every pre-Product Market Fit startup is unlocking a repeatable strategy. According to Andrew Chen of a16z:

“OKRs are almost certainly harmful for pre-P/M fit startups because it causes teams to optimize towards goals as opposed to constantly asking if the goal is even the right one to begin with” [Source]

OKRs need time to master

The industry rule of thumb is that a team must go through several OKR planning cycles to get the process right. Taken at face value, this makes sense. But let’s put a timeline on this: OKRs are usually done quarterly, and if we assume it takes 3-4 cycles to get OKRs right, we’re looking at whole year spent to adopt a management process. A process that takes one year to master is simply wasteful. 

OKR alternatives

Luckily, there are two alternatives to OKRs that are simpler to implement in early stage teams:

• Narrative, Commitments, Tasks

• Impact Maps

#1 NCTs: Narrative, Commitments, Tasks

Hands down one the most effective frameworks, NCTs allow pre-Product/Market Fit teams to manage uncertainty effectively.

NCTs address the most common complaint about OKRs which is objectives and key results that are disconnected from the direction of the company. NCTs solve this by forcing the team to articulate the greater “why” and thus align with the overall strategy explicitly.

The 3-step process for crafting NCTs is simple: 

• First, create a narrative that aligns with the larger business strategy

• Second, define commitments a.k.a. measurable progress milestones that the team needs to achieve within a time frame (usually a quarter)

• Third, define specific product development tasks that will help to achieve commitments

NCTs avoid another OKR pitfall: the Key Results theater when teams try to come up with ways to measure future success without understanding of the current customer or business goals.

Benefits: NCTs are suitable for both tactical planning on the team / group level, and for more strategic goal setting at the department level.

Downsides: NCTs are not as well-known in the industry, and if your leadership is hard-bent on OKRs, they might be a tough sell.

Read more about NCTs on Reforge: Trouble Hitting Your Goals? Here’s Why, and How to Make a Shift.

#2 Impact Maps

Impact Mapping is my go-to framework for quick planning. It was initially proposed by the brilliant Agile methodologist Gojko Adzic. Compared to NCTs, Impact Maps are more tactical, and they work best at an initiative level rather than product level. Nevertheless, Impact Maps can be extremely helpful if a team needs a lightweight approach to plan and evaluate the business upside of their work.

Impact Maps explicitly define the user, a.k.a. actor, whose activities help the business to hit goals. This feature contextualizes said goals and make them feel more tangible, which in turn allows to make planning with Impact Maps more focused.

Benefits: Impact Maps are intuitive and most teams can create them with little to no prior training.

Downsides: Impact Mapping helps define ways to achieve goals, but the framework will not help you question whether your goals are correct.

Want to work with me?

I work with founders and early-stage product development teams at Seed and Series A startups.

Let's talk if you need help accelerating your product execution and the search for PMF, setting up product discovery, and building a product team.

🚀 My calendar is open: https://calendly.com/evgeny-lazarenko/founder-product-coaching

Alternatively, you can hit me up on LinkedIn.

Hello there! Welcome to my eclectic newsletter. My name is Ev, and I blog about technology and product, with a dash of strategy and a pinch of trends.

Today we will review a couple of universal human-centered design principles that web3 products break consistently. (And think of potential solutions.)

Web3 is in crisis, and I’m not talking about the crypto market nosedive. It’s in a crisis of basic usability. And while most new technologies are not polished, to get web3 products into the hands of the majority their developers must show more than a simple conviction that blockchain tech can change the world. Crypto maximalism has run out of steam.

My bet is that to empower the rest of the world through crypto, we must get back to the universal principles of design. In total, there are seven such principles. While all of them are important, two are consistently violated by most web3 product development teams.

Principle #1: Simple and intuitive

All products intrinsically have learning curves. For instance, learning to ride a bicycle is easier than learning to pilot a fighter jet, owing to the complexity of a jet. While consumer web3 products are not jets, they must be as easy to use as their web2 analogs. Right now, adopting a typical web3 product requires a lot of work, and it shouldn’t be.

Imagine you’ve built a decentralized web3 Instagram. To sign up, your users must have an Ethereum Name Service address. Cool. Now they also need to figure out how to get that ENS handle. To get the ENS, they need a wallet, and they need to figure out how to create one, and so on. You get the picture.

The Simple and Intuitive principle means that the product is easy to understand, regardless of the user’s past experience, knowledge, language skills, or concentration level. Unless we bring the level of web3 complexity down to “I can create an account with just an email”, it will continue to put brakes on the growth of otherwise groundbreaking products.

Ways to solve for simplicity and intuitiveness

The lazy way: Education

Have you ever wondered why every web3 startup is trying to educate its users about the benefits of crypto tech, how to use the product, and how to make sense of it? For the exact same reason why web1.0 and early web2.0 products were trying to educate their early adopters: pushing out educational content is faster and easier than solving the hard adoption and interaction problems.

Education is necessary, but insufficient, as it offers diminishing returns. After all, a typical user cares more about getting their problem solved, rather than learning exactly how your product does it under the hood.

The user-friendly way: Progressive disclosure and micro-interactions

Recall the last time you used a product that anticipated your next action and gave you just the right amount of information to make a decision. A product that, despite its complexity, made you feel smart, powerful. When we see products like this, we call their user experience “seamless”. There are, of course, seams. Someone stitched those interactions together, but they hid the complexity away from you as a user.

Principle #2: Tolerance for error

Accidentally shared your wallet where you shouldn’t have? That will be 100 Eth, thank you for your contribution to our scam. Ciao! Next time, think before you act.

The laughable security of self-custodial web3 products against social engineering attacks is to blame for the never-ending stream of Twitter threads that tell sorry stories of lost riches. It doesn’t have to be this way. 

Web3 products that aim to win consumer hearts must be designed in ways that prevent user errors. Specifically, this means that they must minimize risks and negative consequences of accidental or unintended actions.

Consider modern neobanks, such as Revolut, Wise, and Monzo. One of the beautiful things about them is that their users have a plethora of ways to protect themselves from potential fraud, such as transaction notifications, per-transaction 2FAs, and even burner credit cards. Sure, sometimes those things get a little annoying. But hey, I’ve never been a victim of credit card fraud just because I entered my card where I shouldn’t have.

Imagine if you could create a burner wallet in your Coinbase account, get that airdrop, and then transfer it to your standard wallet. Some web3 products are actually starting to implement this approach, but it is still not as popular or accessible as it should be.

Ways to improve tolerance for error

The lazy way: Ask the user to be careful

Seriously, why we’re still doing this?

The user-friendly way: poka-yoke, aka error-tolerant design

Error-tolerant designs employs behavioral constraints that force the user to stick with a specific series of actions. For instance, if you’re connecting a wallet to a service that you’ve never interacted with, a burner wallet can be spun up automatically to minimize risk.

Curious to know more about the design patterns that could work in web3?

Check out my previous post: A case for web3 superapps.

Illustration by Icons 8 from Ouch!

Hello there! Welcome to my eclectic newsletter. My name is Ev, and I blog about technology and product, with a dash of strategy and a pinch of trends.

Today, I’m wrapping up The Writing Guide for Product Managers (Part 1, Part 2) by sharing the books that helped me to level up my writing skills.

Many of you asked whether I could recommend any resources on writing. Indeed, I can. Before that, a bit of background.

I think through writing. Always a bookworm, I tried writing my first piece of fiction when I could still count my age with single digits. Later — as a teenager — I was hoping to study literature, but ended up attending an engineering school. Yet, my passion for the craft of writing never faded.

Eventually, I found myself producing heaps English text: research papers, a doctorate thesis, blog articles, product documentation. The more ink I spilled, the more I became aware of the lexical and grammatical idiosyncrasies that speckled my work, which is a fancy way of saying that my writing sucked. Sadly, I didn’t know how to improve it.

One day, I stumbled on a book that taught me how to think about the narrative structure of a sentence, and how to find language constructs that made the text easier or harder to comprehend. Several other books in similar vein followed.

In this post, I’m listing all of those books and rank them by how much they helped me to improve. If you’re a beginner, and you only write non-fiction, these four books have everything you need to get from 0 to 80.

#1 The Reader’s Brain: How Neuroscience Can Make You a Better Writer

While there’s not much neuroscience in this book, Jane Yellowlees Douglas’s work is packed with careful analysis of good and bad writing patterns — mostly bad. In this way, the book teaches you to recognize writing pitfalls that permeate modern communication. Eventually, you will start seeing those patterns in your own writing. That alone will help you get better.

Amazon: The Reader’s Brain: How Neuroscience Can Make You a Better Writer

#2 On Writing Well: The Classic Guide to Writing Nonfiction

William Zinsser’s work is a classic. Zinsser was a lifelong student of the narrative craft, taught writing at Yale, and published over a dozen books on various aspects of writing. He’s thesis was that “writing improves in direct ratio to the number of things we can keep out of it.”

Not only On Writing Well teaches how to write — it teaches you how to cut. It also equips you with a bunch of principles and fundamental techniques that The Reader’s Brain doesn’t cover.

Amazon: On Writing Well: The Classic Guide to Writing Nonfiction

Read this book if you’re already applying techniques from The Reader’s Bran, want to level up, to learn how to think about your writing process.

#3 Writing with Style: Conversations on the Art of Writing

A little dry, a little academic, but packed with solid advice nonetheless. Trimble’s work reinforces the lessons from The Reader’s Bran and On Writing Well, even though it does so rather formally. Despite being on the heavier side, this book can be a worthy addition to your writing curriculum.

Amazon: Writing with Style: Conversations on the Art of Writing

Bonus: #4 The Elements of F*cking Style: A Helpful Parody

Heard of Strunk’s Elements of Style? Same thing, but reimagined for the spiffy 21st century writer. :)

Amazon: The Elements of F*cking Style: A Helpful Parody

Illustration by Icons 8 from Ouch!

Hello! Ev here. If you subscribed to The Product Thinker between February and May this year, you noticed that I haven’t written much. 

I’ve planned a series of posts focusing on web3, entrepreneurship, 0-to-1 product strategy, and a little bit on life design.

But first, here’s what I’ve been up to since February.

Searching for a better work life

In November 2021, I switched teams at Unity. Initially, my new role seemed like a fit, but by February it became clear that the product didn’t align with my skills or interests. We started out with a 0-to-1 bottom up B2B product hypothesis, pivoted it toward heavy Enterprise use cases, and then eventually scrapped everything and turned the product into an internal tool.

Since I don’t work on internal tools or Enterprise products in principle, I felt like it was time to say goodbye. Not knowing whether another internal move would be possible, I started looking for opportunities outside of the company.

I prepped for a few FAANG interviews but failed all of them despite hundreds of hours of mock interviews. This was unnecessarily stressful, and I decided to avoid companies that practice this style of interviews. (More about this in a another newsletter.)

After the FAANG fiasco, I spoke with other B2C tech companies whose products most of us use daily. The brand names were fantastic, but none of their roles were compelling enough to continue the interview process.

Eventually, a Unity hiring manager who I knew well had an opening on his team, and I joined their mission. While I can’t share the details of I’m working on, it’s somewhat related to web3.

Figuring out my startup interests

I don’t intend to build a decades-long career in product management. In fact, being an employee for my entire life sounds like nightmare. I became a PM because this role prepares me to become a founder better than most other roles in tech. There’s one question that I’ve struggled to answer for years, though: “What kind of company do I want to start?”

As a tech generalist, I’m broadly interested in a variety of technologies and products. I worked on everything from consumer dating apps to B2B SaaS. If you want to maximize your career options as an employee, then having a range is great. But if you want to start a company, you need focus, and I lacked it for years.

Recently, I got rejected from the OnDeck Founders program. It probably had something to do with the fact that instead of picking a clear area of focus as a founder, in my application I chose a bunch of disjointed industries which I was interested. I basically told them that I’m cool to work on anything from AI to Blockchain, to B2B SaaS, Climate tech, and Hardware.  

“Okay dude, you don’t now what you want,” must have thought the person who reviewed my application before hitting the Reject button.

This rejection sparked a realization that as a founder who doesn’t focus on a specific industry niche, I’m bound to waste effort — and my precious time on Earth along with it.

I figured that my success as an early stage founder depends on three factors: focus, effort, and luck. While it’s impossible to control luck, with enough focus and effort I can find the right combination of market and problem to solve. Worst case scenario here is that I could build a lifestyle business and become an Indie Hacker, which isn’t too shabby. :) And so, I focused.

Deciding to focus on web3

In November of 2010, I sat in my dorm in Tokyo reading about Bitcoin. It was late evening, and I was tired after a day of work at my research lab. I gulped some Asahi beer and decided to not buy BTC, even though it was priced at $10 only.

In my defense, there was no clear way to buy BTC then: I’d need to set up a PayPal account which I didn’t have and figure out how to use it without a credit card, which I also didn’t have. After all of that fintech wrangling, I’d have to transfer money to one of many shady exchanges in hope that I could finally buy some BTC. (The most reputable exchange at the time was Mt Gox. We all know how that worked out.) Years later, I made a similar mistake with Ethereum, which traded at ~$70 at the time.

The 2020 NFT craze put crypto back on my radar. As I dug deeper into the rapidly developing blockchain tech stack, it became obvious that we’re entering the third major crypto wave, the one that will last a while.

Unlike many, I’m most interested not in the DeFi applications of web3, but in consumer social. In my opinion, web3 introduces new models of ownership for different classes of knowledge and information assets. This, in turn, creates opportunities to change how consumers behave online and even offline. Here we’re talking about everything from creator economy, to gig work, to customer loyalty.

Long story short, I decided to focus all my product work on web3, hence the upcoming shift in my writing from conventional product topics toward web3 product development and strategy.

Stick around, and let’s explore this space together. :)

My name is Ev, and every week or so I publish a blog about technology and product, with a dash of strategy and a pinch of trends.

🎤 If you have a question, you can ask me in the comments section below.

In this post we will cover:

• A brief history of superapps

• How superapps make use of their financial layer

• Parallels between web2 and web3 superapps

• Why superapps might be one of the key strategies for web3 products

Web3 is misunderstood. The core technologies behind web3 take second place due to the speculation birthed by the NFT community and the religious devotion with which crypto acolytes proselytize decentralization. I get it, but web3 is so much more than that.

Today, crypto tech is rarely evaluated on its merits in a true product sense. In this post, I want to move away from the popular WAGMI narrative that “crypto will change the world!!!11”, and instead think of some of the ways this might actually happen.

Before I continue, you must know that I’m neither a crypto maximalist, nor minimalist. Instead, I like to call myself a crypto pragmatist. Blockchain tech has a proven ability to change the lives of many people, it’s got a broad enough user base to be considered a success, and it’s tech stack is developing rapidly. We do need to iron out a few kinks, but the fundamentals are falling into place.

Two biggest questions pop up in my head every time I see a new piece of technology: “Where have I seen this before?” and “What human behaviors can be made easier with this?” These questions are important because any successful technology is successful due to how seamlessly it embeds itself into our lives, i.e. how it amplifies existing use cases and whether there’s a competing tool or process that already does the job. This gives breakthrough consumer technologies low barriers to adoption and high stickiness.

To answer the question about how web3 might change the way we interact with technology, you don’t need to have Isaac Asimov’s imagination. Instead, you only need to look at how hundreds of millions of consumers go about their day.

A computer in your pocket

In 1990, Marc Porat, the founder of General Magic wrote to John Sculley, then CEO of Apple, Inc.:

“A tiny computer, a phone, a very personal object . . . It must be beautiful. It must offer the kind of personal satisfaction that a fine piece of jewelry brings. It will have a perceived value even when it's not being used... Once you use it you won't be able to live without it."

General Magic failed to turn that vision into reality, but Apple didn’t. With the launch of the iPhone in 2007, users got a hyper-personalized window into the internet. Consumer interactions with technology started to change. First, we began playing Bejeweled on a subway ride. Then the App Store opened the floodgates. In a few years, we had apps for any use case: sharing photos, splitting bills, taking rides, ordering food, listening to music, paying for stuff, organizing our day.

Paradoxical thing happened. Even though more apps got published on Apple App Store and Google Play over time, the count of mobile services we use daily and monthly remained the same over the past 5 years: 

• In 2017, we used 10 apps a day, and 30 apps per month (source: data.ai, nee App Annie 2017 report, link 1, link 2)

• In 2022, average user has 80 apps, but only uses 9 a day, and up to 30 per month (source)

From the perspective of an individual consumer who uses conventional apps, we have reached saturation and a peak of value creation on mobile.

The old App Annie’s report said something else:

“By and large, consumers prefer to manage their lives through apps. For many industries, apps are increasingly becoming a must-have.”

With their WeChat superapp, users in China have known this all along.

Superapps are the operating systems of your daily life

Initially, the term “superapp” was suggested by the BlackBerry founder Mike Lazaridis. He defined it as “a closed ecosystem of many apps that people would use every day because they offer such a seamless, integrated, contextualized and efficient experience.”

WeChat, the most famous superapp in the world, offers services which users can access in various contexts as they go about their day. Want to pay for your morning coffee? Here’s the payment functionality. Want to split the bill with your friend? You got it. Want to send money to your parents in another city? Easy. Want to book a concert ticket? Find a restaurant and make a reservation? Order pet food? With WeChat, you can do all of that. Indonesian GoJek and Singaporean Grab are in the same category.

What Mike didn’t talk about is how exactly the services work together. Not only super apps offer high day-to-day utility to users, but they are often interoperable. The latter feature is made possible by a fintech layer that most superapps have. That financial layer is the not-so-secret sauce that helps superapps to facilitate transactions and contribute to their utility.

The financial layer of superapps

Between 2019 and 2020 I worked at Grab, one of the biggest superapps in Southeast Asia.

Grab nailed its superapp strategy and created an extremely sticky product: each of the apps within Grab’s ecosystem embeds itself in the daily lives of consumers. Grab users can book rides and peer-to-peer deliveries, order food, pay for various online and offline services — all from a single application.

The absolute majority of those transactions are done through a wallet service called GrabPay. Owing to its relaxed KYC procedures, GrabPay was able to penetrate the previously unbanked demographics in the Philippines, Indonesia, Vietnam, and others. With GrabPay and the rest of the superapp services, Grab’s users are now empowered to participate in the economy.  The successful march of GrabPay across Southeast Asia culminated in Grab Financial Group getting a digital banking license from the Monetary Authority of Singapore in 2020.

When I briefly worked at Delivery Hero on their Foodpanda food delivery and quick commerce app, one of my sister teams was building a stored value wallet as a way to capture the money and recirculate it within the ecosystem. Wallet, as the team recognized, was the key component missing in Foodpanda’s superapp strategy.

With a financial layer in place, when users pay for food delivery, restaurants can use a share of that revenue to sponsor promoted listings or discounts. This is a very practical use case, and at one point Grab was exploring ways to make restaurants and merchants pay for advertising using the GrabPay dollars which they earned from eaters in the app. 

Based on how prevalent marketplace dynamics are in superapps, I have my own, more modern and specific definition of a superapp:

Superapp is a multi-service marketplace complete with a financial transaction layer. Within the superapp marketplace, trust is guaranteed by the platform that runs it.

From that definition, you can see that the superapp patterns fits web3 narrative well.

On Web3 and product patterns

First, let’s admit that the majority of web3 products are arcane: they have high barriers to adoption, and their usability is low. As for utility, it’s usually limited to niche use cases. This is expected from technology that is very much in its infancy. Recall the Web 1.0 of mid-90s: Fidonet, IRC, and the world before JavaScript. The Internet sucked for much of it’s early days.

Things are changing, though. Software wallets decreased onboarding friction and made it easy for new users to work with crypto. Getting started is now so simple that I was able to set up a Metamask wallet in just a few minutes.

In every new technology, certain UX and product patterns become de facto standards. Hashtags, popularized by Flickr, became one of the prime patterns in modern social networking. Algorithmic timelines helped Facebook, Twitter, LinkedIn, and others to dominate social. And, of course, we all use “skip intro”, “slide to unlock”, and “buy with one click”.

Web3 will not be an exception. Some patterns and mental models will come to dominate the field. You already see this happening: almost all crypto products rely on onboarding flows to introduce new users to their concepts, and use communities and academies to build stickiness. This is now done with Discord and panoply bots, but the idea is similar to onboarding web2 products of the early 2010s.

Superapp might be another such pattern. Based purely on what I’m seeing in web3 from a product design perspective, I believe that we will see more and more web3 products turning themselves into superapps. This is a match made in heaven:

• The DeFi layer of web3 is a basic building block of the system

• Many web3 products are showing marketplace dynamics which fit the the superapp pattern

• Superapps can help to recirculate value in DeFi marketplaces

Web3 vs web2 superapps

While web2 superapps are closed proprietary ecosystems, web3 superapps will be decentralized natively. With this comes a scaling advantage: in theory, web3 superapps will be able to add new services on demand. 

Imagine a web3 analog of Airbnb that not only helps to book a place at your next travel destination, but also helps you arrange breakfast delivery or a brunch spot reservation for a few days that you’re there. That same product could facilitate the transactions between the host and their learning services provider. 

Of course, all of that is possible now, but it requires tight platform and business coordination, as well as integration between all parties involved: the booking platform for properties, restaurant booking platform, learning services providers. Colloquially, this is called integration hell.

Because identity verification and trust are built into web3 superapps, they have a potential to escape integration hell by design. This, in turn, increases the range of services available in a web3 superapp and drives its growth. Here, web3 platforms will move away from solving the problem of integration, and toward solving the problem of curation.

As a product manager, I’m excited. Web3 superapps open the opportunities for stitching many services into curated, even personalized experiences, and that will create a whole new category of products. As Kevin Kelly wrote some eight years ago:

The last 30 years has created a marvelous starting point, a solid platform to build truly great things. However the coolest stuff has not been invented yet — although this new greatness will not be more of the same-same that exists today. It will not be merely “better,” it will different, beyond, and other. But you knew that.

What you may not have realized is that today truly is a wide open frontier. It is the best time EVER in human history to begin.

Hello there! The Career Product Manager is now The Product Thinker. Welcome :)

My name is Ev, and every week or so I publish a blog about technology and product, with a dash of strategy and a pinch of trends.

🎤 If you have a question, you can ask me in the comments section below.

Product Management is weird. At a single company, the role will differ depending on the product area and the stage of product lifecycle.  

Reforge, the leading learning platform for experienced product managers, identifies four product specializations with eight sub-specializations in each. That’s thirty two permutations of how the job of a PM might look like. This stuff gets overwhelming real quick.

If you’re a startup founder building your core product team, what should you look for? The key is not to focus on specific traits and experiences of an ideal candidate, but to think deeply of the impact you want them to create.

Work backwards to define the role

Here’s the main mistake founders make: they start with a job description. Thinking about job requirements and skillsets may seem like an obvious thing to do, but in reality this is counter-productive. You don’t build a product by listing its features. Instead, you start with the problem the product solves, your vision for it, and the impact it will have on the customer and the business.

Similarly to creating a great product, building a great product team requires you to think of the problem that team will tackle in your company. Consider the future you want for your startup, then write a vision for the team. Here are some questions to inspire you:

• What will the company and the team look like a year from now? 

• What impact will the team have created by then? 

• How will product managers work with engineers, designers, data scientists, operations, marketing, sales? 

• How will they work with you? 

• How will you know that the team is performing well?

Answers to those questions will help you map what you’re looking for in a product team. Once that’s done, a job description and an interview plan will come easy.

Planning your product interviews

You can evaluate engineers by looking at their code and designers by reviewing their portfolio, but you can’t do the same with PMs. Their work is intangible, and separating the great product manager from the average is hard. 

On the most basic level, product management is an experiential craft. To see how good someone is, you need to know:

• how they solved problems in the past

• how well they could stretch their skills to help your company

You can do that with evidence-based questions and case studies.

Using evidence-based based questions to evaluate past performance

Evidence-based questions are contextual, and they aim to show how candidates solved problems in the past. Those are the questions that start with “Could you tell me about a time when … ” 

As the name suggests, such questions are designed to find evidence of past performance and help candidates give situational examples of how they tackled product challenges in their career. The main idea here is that grounding a question in a candidate’s unique experience helps to reduce bias.

The problem with evidence-based questions, however, is that the contexts they unearth aren’t always relevant to your company. As I mentioned earlier, product roles are incredibly diverse, which means that deep experience of certain candidates may look irrelevant at first.

For instance, if you’re interviewing a product manager to join a B2B SaaS startup, but their past work was in B2C, you may find it hard to connect their experience with the reality of your organization and team. This doesn’t mean that such candidates can’t help your company. You just need to dig deeper. This is where case questions come handy.

Using case questions to measure future potential

Case questions give candidates a hypothetical problem that they must solve in a short amount of time. They typically look like this:

• Design X

• Improve Y

• Define a strategy to launch product A in a new market B

Case questions are the hardest product questions, because they require candidates to demonstrate both breadth and depth of their craft in a 20 to 30 min conversation. Many candidates don’t like case questions for two reasons.

First, cracking them requires a massive amount of prep. The prevalence of case questions in Tier 1 tech companies gave rise to a cottage industry of interview prep companies like Exponent or Daily Product Prep. It’s not uncommon for product managers to spend tens of hours on preparing for product case studies, only to get rejected.

Second, case questions are impersonal. They often feel unfair when used in isolation, because they don’t allow candidates to show the full spectrum of their skillset. Therefore, it’s best to use case questions in tandem with evidence-based questions.

💡 Tips for using case questions: 

• Only use case questions in combination with evidence based questions.

• Always ask more than one case question.

• Never make case questions about your company or domain. As a founder, you have insider knowledge, and that will skew your evaluation.

Sample interview plan

Below is an example plan that aims to ask a series of evidence-based and case questions over the course of 60 min. (You can also see it in Google Docs at this link.) Use this example plan to create your own plan.

Prepare to answer their questions

Good product candidates will ask deep questions about your business, your team, and the way you think about organizational design. Here are a few non-negotiable questions that you as a founder must have answers to.

• How do you define the role of a Product Manager?

• Can you tell me about the last time you killed a product or invalidated a hypothesis? What did you learn?

• What is your value proposition?

• How do you differentiate?

• What’s your vision for 1, 3, 5 years from now?

• What does your 1 year roadmap look like?

• Who will this role report to?

• Can you tell me about the structure of the team? Who will I be collaborating with most closely?

• Have the engineers on the team worked with a Product Manager before?

• What does a career ladder for PMs look like at your company?

• What is the one single metric that a PM in this role will own?

• What is the onboarding plan for this role?

• What is the 3 / 6 / 9 months plan for this role?

👉 Want to know what other questions candidates might have up their sleeve? Check my post about strategy questions you might get asked as a founder: Joining a startup? Ask them about strategy

Illustration by Anna Antipina from Ouch!

Hello there! Welcome to my eclectic newsletter. My name is Ev, and every week or so I publish a blog about technology and product, with a dash of strategy and a pinch of trends.

🎤 If you have a question, you can ask me in the comments section below.

Welcome to Part 2 of the Writing Guide for Product Managers. In Part 1 we talked about 10 principles of good writing. (If you missed it, read it here.)

In today’s newsletter I’ll share actionable techniques that you can use to create structure and flow in your written work.

The reader’s journey

Product reading is not sequential. Your readers scan through documents and jump from one section to another. The document you wrote might be important to you, but to them it’s one of many they have to read today. Once they open it, several questions will be on their mind:

• Do I need to read this?

• How deeply? Which sections can I skip? Which sections can I skim? Which ones should I read thoroughly?

• Do I need to provide feedback?

Only one part of your job as a product writer is helping readers gain new information. Another part is helping them understand whether they need that information at all. This is where structure comes in.

Good structure helps readers to navigate the document, and to decide how they should work with it. Below are the simple techniques for adding structure to your written documentation.

#1 Build your information architecture upfront

Each document you create has an internal information architecture, and your readers rely on it to make connections between ideas in your narrative. Well-designed structure is like a series of bridges that guide the reader from one section, bullet point, or footnote to another. On the other hand, poorly crafted information architecture makes it hard to understand the document. It’s like swimming in an endless pool of lukewarm drinkable yogurt. Yuck.

When working on each new product document, I like to outline the structure before committing any ideas to paper. That helps me catch inconsistencies in my thought process and find the best way to sequence the sections and chunk the narrative.

#2 Bullet points: no more than 3, with summary

From a stylistic perspective, I’m not a fan of bullet points. They are a sign of unimaginative utilitarian writing that has been stripped of soul in exchange for function. While I avoid them when I can, their bare utility sometimes comes handy when explaining 

• categories,

• options,

• sequences.

Despite their lack of style, bullet points work well when you want the readers to quickly scan the text and pick the elements of it that they deem relevant.

Note: I’m deliberately not mentioning checklists in this section, because that’s a different, specialized use case.

#3 Be specific

Being specific means not leaving anything to interpretation. Let’s look at this sentence: “Significant number of users performed Action Z after the release”. What is a “significant number”? What does “after the release” mean? We can edit that sentence and get straight to the point: “X% of users performed Action Z within 1 week after the release”.

#4 Add a TL;DR

Some of your readers will want to know every single detail in your document. Others will only seek a high-level summary. Unfortunately, when they see your doc for the first time, they won’t yet know whether they want to read the whole thing or not. You need to help them figure that out.

A three-sentence summary that contains the main idea of your business opus will help the readers to decide whether they want to be lightly informed or deeply engaged.

#5 Emphasize in bold to help readers skim

Sadly, readers don’t dedicate all of their brain cycles to our writing. Slack and email notifications, domestic work-from-home or office interruptions chip away from their attention span, and we, writers, are left with scraps. It won’t get better, and all that’s left is to adjust and make use of what we have.

Emphasizing text in bold is a crude yet effective way to do just that and to point the inattentive reader towards the most important ideas in our text. While the readers may not grasp the details, skimming through key ideas is enough to equip them with basic understanding of our message. Not perfect, but good enough for them to not feel lost in that all-week meeting that started last Monday.

#6 Add flow charts to help skim

A lot of product work hinges on our ability to understand user journeys, data flows, processes. We tend to talk about all of those things, even when the best way to share our insight is to show our readers a flow chart. 

BONUS: Style guide for your slides

I’m not a fan of slides, but here are several formatting tricks that make slide decks easier to digest:

• Each slide should make only one point.

• Slide titles are your headlines. (Remember the pyramid principle?)

• Text within the body of a slide should be the same size

• All titles within the deck should be the less than 2 lines of text

• Use visuals and infographics when you can

• In the slide body, avoid long blocks of texts (more than 2 lines)

Hello there! Welcome to my eclectic newsletter. My name is Ev, and every week or so I publish a blog about product, technology, career, or life in general. But usually it’s the first three. 😉

🎤 If you have a question, you can ask me in comments or in a form here. I will answer it in one of the future posts.

Think of a patient who has just been diagnosed with a rare type of cancer. Now imagine a world where, within two hours after a biopsy, the lab comes up with a personalized drug formula that can kill the cancer. Within two days, the compound is synthesized, and the patient begins their treatment which is safe, efficient, and affordable.

Imagine a world where you hop on a red eye flight from New York to Tokyo, and the first thing you notice is how quiet the cabin is: you don’t even need to use your noise canceling headphones. All you hear is a hum of all-electric engines.

The engineers who built this plane didn’t use heavy lithium ion batteries. Neither did they use conventional materials to build the structure of a plane. Instead, they came up with entirely new materials that made the batteries energy-dense and the hull strong at a fraction of a weight of the planes we fly now.

Now imagine that this is not science fiction, because the path to such a world is becoming increasingly clear. We will reach that world by building computers so powerful that they allow us to calculate how atoms in large and complex molecules combine and create unique properties. Those computers will also help us design new drug molecules, create new materials, and build simulations of the physical phenomena that we simply cannot grasp today.

The first commercial versions of such computers are already here. They are called Noisy Intermediate-Scale Quantum (NISQ) computers, and they are about to change our world.

What exactly are NISQ computers?

The term NISQ was coined by John Preskill, a Caltech professor of theoretical physics. For more than two decades Preskill has been working in the field of quantum information science. In his definition, NISQ computers are quantum computers with a modest 50 to 100 qubits, hence the label “intermediate-scale”. They are “noisy”, because quantum bits within them are unstable and experience what’s called “quantum decoherence”.

Decoherence means those qubits may lose their quantum properties (and the resulting advantages) during their operation leading to errors in computations. Correcting such errors is a hard science problem, and multiple research groups are testing different approaches and algorithms.

Despite many recent breakthroughs in quantum error correction, researchers are yet to achieve reliable correction in NISQ computers. Because of that, engineers don’t use quantum computers as primary workhorses. Instead, they use them as quantum co-processors which work alongside conventional computers within a datacenter and handle the most difficult computations which would take, quite literally, the age of the universe on a classic machine.

The economics of early quantum computing

Commercial NISQ computers are now entering the market, and developers can access them as cloud compute instances. Several companies operate on the cloud compute model. Among startups, those are D-Wave, IonQ and Rigetti. All three rent their hardware via Amazon Bracket. (Rigetti is also available on Microsoft Azure.) Among the more established companies, IBM offers cloud access to its hardware. 

IonQ and Rigetti have recently gone public via SPAC mergers, and we now have access to some of the information about their business. From their investor presentations, it’s clear that both companies are in the earliest stages of commercialization. IonQ booked about USD $16M of revenue in 2021, while Rigetti made $6.9M in the first nine months of the same year.

The daunting task that both companies face is no longer in building the hardware: they’ve already shown they can do that. Instead, it’s finding viable commercial use cases. All quantum hardware manufacturers agree: because their gear costs a pretty penny, the only way to pay for it is to serve the most financially powerful institutions of the world, also known as investment banks.

Therefore, IonQ has partnered with Goldman Sachs and Accenture to develop business applications for quantum computing. Rigetti, even though it hasn’t disclosed specific partnerships, is also working with the leading financial institutions on fintech use cases. 

Charting the industry dynamics

In order to understand where the quantum tech industry might go next, we only need to think in plain economic terms of cost and demand. Not only quantum hardware manufacturers are now spending hundreds of millions on core R&D, they are also creating their own software. This is happening despite the limited number of sectors where such hardware and software could be deployed. 

When the growth in those sectors eventually slows down, the incumbents will be forced to reduce costs. They will simplify their product lines and unbundle their activities by focusing on singular areas of competence, such as specialized quantum hardware, generalized quantum hardware, specialized and generalized software. This will open the markets to new entrants in all of those areas of quantum tech, and we might see a new S-curve of unparalleled technological advancement. 

Similar processes have happened in the second half of the 20th century with classical computers: microprocessor manufacturers were also building custom software, but eventually they had to close down software divisions and concentrate on the core hardware competencies. The outcome of that was the rise of Microsoft, Oracle, and the rest.

When will the mere mortals benefit from quantum computing?

The short answer is somewhere between 2025 and 2040. The detailed answer is more complex.

Public roadmaps from Rigetti, IonQ, and PsiQuantum, alongside a variety of industry reports, all point towards the ten year period between 2025 and 2035 as the era of so-called broad quantum advantage. Broad quantum advantage means that quantum hardware will become reliable enough and affordable enough to solve the problems which conventional computers simply can’t tackle.

Some of those problems are: climate simulation, energy distribution, computational drug discovery, computational fluid dynamics. We just have to wait a little longer.

A personal note about quantum computing

Quantum computing fascinated me since I was a teenager. I learned about D-Wave in 2003, four years before the company successfully demonstrated the first ever functional quantum computer. Since then, I kept tabs on the technology and followed its development trajectory and R&D milestones closely.

As quantum computing technology matured in the fifteen years that passed since D-Wave’s demonstration in 2007, the narrative around it shifted from “does this thing really work?” to “how can we make money with it?” Venture capital dollars poured in, companies went public, and multiple industry juggernauts launched their own hardware. It certainly feels like the quantum computing industry is about to start a period of hockey-stick growth.

Sources:

• John Preskill: Quantum Computing in the NISQ era and beyond

• IonQ: Annual Report 2020, Investor Presentation Sep 2021, Q3 2021 Earnings Transcript, Q3 2021 SEC Filing

• Rigetti: December 2021 Investor Update, October 2021 Investor Presentation

• IBM: Annual Report 2020

• BCG: Building Quantum Advantage

• Protocol: Investors tell us why they’re pouring millions into quantum computing

Illustration by Icons 8 from Ouch!

Hello there! Welcome to my eclectic newsletter. My name is Ev, and every week or so I publish a blog about product, technology, career, or life in general. But usually it’s the first three. 😉

🎤 If you have a question, you can ask me in comments or in a form here. I will answer it in one of the future posts.

Good writers get ahead

“Hire good writers” is a rule that Jason Fried and David Heinemeier Hansson live by. Founders of 37Signals, the company that gave the world Ruby on Rails, Fried and Hansson have built a distributed team whose success hinges on an ability to communicate asynchronously across time zones and cultures. 

Fried and Hansson are not alone in their belief that writing skills matter. Founders of GitLab, Stripe, and Amazon have all nurtured cultures of strong written communication.  

Clear writing helps your colleagues to answer questions in a timely manner, it helps them learn, and to make better decisions. In a world that’s becoming increasingly distributed and asynchronous, writing is regaining its importance as the most important way of communication.

About this guide

I will publish this guide as a series in three parts: Principles, Techniques, and Resources — all covering different aspects of the craft of writing. Today, we will start with principles.

Principles

#1 Write for yourself

You will hear this often: “know your audience”. While this advice works well for public speaking, it may lead you to a writing disaster. William Zinsser suggests a better, contrarian approach: you should always write for yourself.

Of course, that doesn’t mean completely ignoring the needs of your audience. Instead, that means allowing yourself to rely on your innate feel for language and understanding of context of whatever it is you’re trying to explain. This helps you craft a message that not only conveys information in with clarity, but does so without sacrificing your unique voice.

Few things are as boring as jargon-laden business documents devoid of style and life. While often sometimes efficient, business writing, and especially product management writing, is rarely memorable.

Your job as a product manager, however, is not only to provide information, but make it memorable and easy to recall, so that your colleagues could apply the new knowledge in their work. If after reading the draft you get bored to bits, you know what to do: rewrite.

#2 Rewrite

Every single accomplished writer admits that the most powerful tool in writer’s toolbox is rewriting. Your first draft, be it the first draft of an email or the first draft of a product strategy, is never good enough. Rewriting is the single most important thing you could do to bring clarity and narrative cohesion to an otherwise nebulous mess.

The challenge, however, is to know how to rewrite. All of us have unique writing struggles that we must overcome. Some abuse passive voice, while others use too many weasel words, thus not being specific. Once I started fostering good writing habits and learning more from professional writers, I began paying close attention to my own writing mistakes—and the mistakes of others. As I did that, I realized how tools that do miracles for me can’t help my peers. Everyone needs to figure out their own approach. 

Part 2 of this series of articles will give an overview of techniques that you can use to come up with your unique way of rewriting. I hope that it saves you time, and you can become a better writer in mere weeks, instead of months or years.

Subscribe now

#3 Cut 50%

Once you finish writing, cut the draft by half. It’s a difficult goal to reach, and you won’t be able to do that every time, especially as you get more skilled as a writer. But even good writers can expect to cut the amount of words they used in the first draft by a third.

One of my former colleagues communicated with a sniper-like precision, and one of the reasons for that was his habit of cutting. He forced himself to cut: every paragraph he wrote, he challenged himself to convey the same message in just one sentence. Obviously, he didn’t just cut, but also used paraphrasing a lot.

Let’s take a look an example from a popular business strategy blog Stratechery.

Before [79 words]:

Bitcoin’s value is rooted not in the Bitcoin blockchain, but rather in the collective belief of millions that it is in fact valuable; NFTs, to the extent they capture and retain value, will require the same sort of collective belief (this is why I find NBA Top Shot particularly interesting: it is rooted in real world copyright). That means the real power is not the record of belief, but rather the ability to inspire belief in the first place.

After [45 words]:

Bitcoin’s value is not in its blockchain, but in the belief of millions that it is valuable. NFTs will require the same collective belief. That means the real power is not the record of belief, but the ability to inspire belief in the first place.

Source: https://stratechery.com/2021/non-fungible-taylor-swift/

#3 The inverted pyramid principle

Inverted Pyramid principle is an approach that journalists practice daily. Journalists start most of their stories with a sentence which summarizes the most important facts. That sentence is called a “lede”. All following sentences support the lede with more information, and readers who are short on time only need to skim the main and paragraph ledes to learn everything they need.

Inverted Pyramid is a great way to help people who skim — and most of your readers probably do. In military communication this approach is called “bottom line up front”.

You can apply the Inverted Pyramid on the document, section, or paragraph level. You can even use it to structure your slides.

#5 Read your draft out loud

Reading out loud is the best way to see if your sentence flows. It helps you to taste the sounds on the tip of your tongue: if two words are hard to pronounce in sequence, you need to change them. Some words look fine on paper but have an extra syllable that makes them stick out in a sentence. That also breaks the flow. 

Compare with the first version of that paragraph:

Reading out loud is the best way to see whether your sentence flows, for two reasons. First, it allows you to feel the words on the tip of your tongue: if two neighbouring words are difficult to pronounce, you need to change them. Second, while some words look fine on paper they may be a syllable too long, and that makes the sentence less readable.

#6 Craft the narrative

All previous principles focused on writing with better style. And while style is important, narrative flow of the whole document bears as much weight as clearly written sentences and paragraphs. You may not think about the narrative when crafting a short email, but writing a longer document makes it treacherously easy to veer off track and engage in a self-indulgent exploration of business vernacular without actually saying anything of substance and value. We look down on verbal rambling, but we seem to tolerate it in our writing.

A way out of this is to answer the question: how does the key message of the current section of my document support the key message in the previous section? Another good way to structure your thought is to make each section of the document self-contained.

Self-contained sections that build on each other and use the Inverted Pyramid principle help readers who skim grasp enough context about what’s going even if they choose to read less than half of the document.

#7 Think in 2 .. 4 sentence paragraphs

Thinking in paragraphs instead of sentences helps you find a way to convey a whole concept. You can start with a key message in the lede, expand on it in the next sentence or two, and wrap up with the last sentence to set the stage for the next paragraph. That helps you to make each paragraph logically complete and connected with the rest of the text.

#8 Don’t over explain

There’s nothing more frustrating than reading a lengthy and complex explanation of something simple. 

It goes like this: “In our research, we found strong evidence that X% of users who saw suggested products in their cart checkout flow had Y% increase in order value. Normalized for the entire user base, the results in $Z USD increase in average order value.”

While those sentences are entirely made up, their level of monstrosity is representative of what’s wrong with much of product writing. While those two sentences aren’t specific enough, that’s not the biggest problem. The main issue here is that the text gives an unnecessary level of detail and over-explains the experiment, and that makes it hard to pay attention to the key message: the uplift in average order value.

Here’s a better version: “Users who saw suggested products in the checkout flow submitted bigger orders, with an average increase of $Z USD.”

#9 Simplify

Precise language cuts to the chase. How many times have you seen someone write “utilize” when a good old “use” would do? In our attempts to sound smart, we abuse the language and over-engineer sentences. We “initiate” instead of “starting”, “communicate” instead of “talking”, and “collaborate” instead of “working together”. 

If you’re struggling to simplify, it’s always a good idea to check thesaurus to find shorter words. 

💡 Tip: You will also notice that the overly complex words in our corporate lingo have Latin roots. Swapping them out could clean up your writing in a flash.

#10 Make your last sentence pop

Opening sentences get all the spotlight, but it is the closing words that tie it all together and deliver and emotional or intellectual punchline. There’s not much I can say about how to pick your last sentence, except to say that you should think about it just as hard as you think about your first.

Illustration by Icons 8 from Ouch!

Hello there! Welcome to my eclectic newsletter. My name is Ev, and every week or so I publish a blog about product, technology, career, or life in general. But usually it’s the first three. 😉

🎤 If you have a question, you can ask me here. I will answer it in one of the future posts.

In today’s post I explain the aspects of startup strategy which tech job seekers should review when interviewing with pre-Product/Market Fit to mid-stage venture-backed companies. I’m also sharing a toolkit to evaluate the strategy, and a list of questions to ask in your next interview.

The post-pandemic startup jobs market is hot. Valuations are through the roof, and young companies have the cash reserves to scale teams. Many of them are no longer hiring talent in their country alone. Instead, they bring on board anyone living in the same time zone. (A new term for this is “longitudinal arbitrage”.) For jobseekers, this means many more options. 

You might have a few interviews lined up, and most of them are with companies that fit your life goals. The question is: how healthy is their business? While most startups fail, it’s possible to see signals of potential success early on. The search for those signals starts with questions about the company’s strategy.

Some of those questions you can ask directly in an interview. Some you will have to answer yourself through research, industry analysis, and by talking to current or former employees.

Before we go any further, though, I will make a big assumption. I will assume that you already know your career goals for the next few years and that you know the kind of company you aspire to work at. If you don’t, you can check one of my earlier posts on this here:

Now, let’s dive in.

Four dimensions of startup potential

Strategic advantages

Most startups don’t have a fleshed out strategy until later stages of growth, think Series C or D. This is a fully expected situation, because the whole point of a startup is to iterate on the business in order to find a strategy that can lead to sustained profits in their market.

That said, even in their larvae stage high-potential companies have one or two markers of success that will help turn them into butterflies.

Advantage #1: They have strong differentiation

Differentiation can take many forms, but simply being unique is not enough. What’s true for high-potential startups is that they are the only solution in their specific market segment which gives customers a massive increase in experience or value.

Design tool Figma leapfrogged their competitors InVision and Sketch by making collaboration between designers and frontend engineers easy. Tinder helps users land a date an order of magnitude easier. Uber does the same for getting a ride in rush hour.

To sum it up, high-potential startups:

• Offer a unique solution

• Serve a specific, often narrow, customer segment

• Give customers an increase in performance unmatched by other solutions

You can evaluate a startup’s differentiation in three ways:

• [B2C] You can try their products directly

• [B2C & B2B] You can read reviews on different app stores, Capterra, or G2

• [B2C & B2B] You can ask pointed questions as a part of your interview.

➡️ At the bottom of the post I added a list of questions which you can ask in your next interview.

Advantage #2: They have something that’s impossible to replicate

In business strategy, this is sometimes called a “cornered resource”, which is basically a secret sauce that competitors can’t replicate or obtain. Most often, these are patents or a deep research experiences of the founders. 

This type of strategic advantage is common in deep tech startups, while it’s relatively rare in other kinds of companies.

Market conditions

The footnotes of technology history are filled with mentions of dead startups which in their heyday were considered breakthrough successes: Webvan, Better Place, and many others.

While so much went wrong with each of them, the number #1 factor was the market: they were either too early, served the wrong customer, or operated in a regulatory environment that didn’t support innovation. The bottom line is that even the best products can’t win in a bad market.

Unfortunately, assessing the market is not easy. It requires a set of skills that take time to develop. The shortcut is to ask questions about the market and the industry during your conversations with employers.

Quality of execution

The world is dynamic. Strong differentiation, having a cornered resource, and being in the right market are not enough to ensure sustained strategic advantage. Practically, this means that superior business performance is a moving target. A company runs the risk of failing in the long run if doesn’t make full use of or doesn’t expand their advantages. 

Now defunct Fab.com is a good example of that. The company started out strong, found an initial product market fit, but was unsuccessful in sustaining it. After raising a total of $300M between 2011 and 2013, Fab crashed and burned. Its core assets were sold-off in an all-stock transaction in late 2014 — for just $30M.

Unlike strategy and external market conditions, I find the quality of execution hardest to evaluate. Most startups are black boxes, and as a job seeker it’s hard to see what’s happening on the inside — until it’s too late.

In order to understand how well the startup executes their proto-strategy, we need to ask questions about:

• The actions they are taking to deepen their differentiation

• Their rate of pivots, i.e. how frequently they evolve their strategy

• Their approaches to measuring business and product performance

Talent strategy

And finally, there’s talent strategy. Startups approach hiring in three major ways:

1. They can hire junior specialists to put out burning fires

2. They can hire senior specialists to build out a specific function

3. They can hire mid-level specialists who excel in frontline work but can scale up their contribution as the company grows

First and second approaches are risky. If the startup hires too many junior specialists, e.g. more than 20% of staff, coaching will stretch and distract the more experienced contributors. As a result, productivity will suffer, and with lack of oversight the junior specialists may veer off track, leading to a drop in the quality of execution.

If the startup hires too many senior specialists, they risk staffing the team with people who are unable to function in fast-moving unstructured environments. Another subtle risk here is that some senior specialists might be overly attached to processes and tactics that worked in their past companies but may not work at startups.

The last approach, which is hiring mid-level specialists, avoids both risks. By hiring strong contributors with several years of experience under their belt, startups can ensure high quality of execution without breaking the bank. They also have a higher rate of success at growing those specialists into leaders.

Thankfully, getting a sense of how the startup thinks about seniority and specialization is as easy as checking their LinkedIn profiles. 

Extra reading: Gergely Orosz who runs The Pragmatic Engineer newsletter in is advocating for a similar approach. Check his thoughts on LinkedIn: Gergeley Orosz on building engineering teams.

Summary

Based on everything that I talked about so far, here are principles for deciding your next startup gig:

1. Always pick a company with the strategy that you believe in: their differentiation, unique advantages, and value proposition all must make sense to you. 

2. Great products aren’t enough — the market must value them.

3. Good strategy without good execution is luck. It runs out.

4. Talent strategy should support execution.

Sample list of questions to ask during your next interview

💡 Tip: Save this post, so that you could keep track of new questions. I will be adding them over time.

Core business

• [Value prop] What is your value proposition?

• [Differentiation] How do you differentiate from [name the top incumbent / competitor]?

• [Differentiation] How big of a gain in value or performance do your customers get?

• [Differentiation] How satisfied are your users with the product? Can you share customer success stories or feedback?

• [Cornered resource] Does the company have a core strategic advantage that competitors and incumbents are unable to replicate? If yes, what is it?

Market

• [Market dynamics] What changes have you observed in your market and industry landscape that can help your company become a breakthrough success?

• [Market dynamics] What changes have you observed in your market that unlocked new ways to create value for the customers?

• [Industry dynamics] What has happened in your industry that made it possible for you to challenge the incumbents?

• [Segmentation] In your current market, what are the customers that you decided to not serve?

Execution

• [Quality of iteration] Can you tell me about the last time you killed a product or invalidated a hypothesis? What did you learn? [This questions helps you understand how well they iterate on their tactics and strategy]

• [Quality of iteration] Looking back at the past 3 months, can you tell me about the initiatives that failed? How did those failures help the company evolve its strategy?

• [Roadmap] What does your 2022 roadmap look like? What influenced it?

• [Overall direction] What’s your vision for 2022, 2025, and 2030? 

Talent strategy

• [Team composition] What can you tell me about your people strategy? Does the company prefer to hire junior specialists, senior specialists, or mid-level specialists?

• [Team topology] Can you tell me about the structure of the team? Who will I be collaborating with most closely?

In early 2020, Andreessen Horowitz and several smaller VC firms poured $10M of Series A capital into Clubhouse. Even though the company’s product had 1500 measly users, it was valued at $100M at the time.

What followed was a flawlessly executed go-to-market motion that made Clubhouse invites a hot commodity — first in the US tech circles, then elsewhere.

At the peak of its popularity in early 2021, Clubhouse felt like a global cultural phenomenon. Riding the wave of never-ending media attention, the company raised a $100M Series C which reportedly valued it at $4B.

The party didn’t last. At the dawn of 2022 and in the third year of the pandemic which fueled its meteoric rise, Clubhouse is less relevant than ever. Mentions of the streaming sessions are gone from LinkedIn newsfeeds. Media attention is back to where it was before Clubhouse launched, i.e. in crypto.

The ranking of Clubhouse in the US Apple App Store Social Networking category paints a clear picture: Clubhouse dropped from Top 10 in January 2021 (App Radar) to #67 on November 27, 2021 (Sensor Tower).

One caveat, though: once the Omicron variant began to spread in the United States in early December, Clubhouse climbed back up to top 10. I don’t know whether those two events are correlated, and it remains to be seen whether the inevitable decrease in cases leads to further changes in user sentiment.

Setting aside the popularity spike in December 2021, Clubhouse is pretty much dead. Why did this happen?

Let’s take a look at the basics of Clubhouse as a business, not as a cultural phenomenon.

Clubhouse as an invention

When analyzing Clubhouse, we must ask two fundamental questions:

1. Did Clubhouse make a product breakthrough that created an outsized gain in user value?

2. Was the product differentially attractive enough to pull and retain users?

My answers to those questions are: “It did not”, and “Not at all”.

On the basic level, Clubhouse is a network that serves listeners and creators, also known as hosts.

Listeners

Clubhouse gives listeners an audio-only live streaming platform with a talk-back functionality. By itself, this is a weak value proposition.

When it comes to listener behavior, Clubhouse’s true competition is on-demand content. The convenience factor of such type of content is hard to surpass. There’s a reason why broadcast TV couldn’t compete with streaming: streaming is simply more user-friendly. More about this below.

Creators

When it comes to creators, Clubhouse does not give them an opportunity to engage with audiences in a novel way. All it does is letting them speak live. From a competitive perspective Clubhouse offered nothing new or different to creators: internet live streaming has been around for years (Twitch, Youtube, and many other, smaller players such as Telegram).

The issues with live content

Clubhouse launched with a promise of scaled live audio streaming. Live content, however, is much harder to work with than recorded content. It’s much easier to build and improve a content recommendation system when you have all of it recorded and labeled, and such systems that are key to helping audiences discover new content and engage continuously.

Moreover, recorded content is evergreen. Creators can curate it and distribute it outside of the platform, which allows them to grow their audiences.

Clubhouse doesn’t have true network effects

The key strategic meaning of a network effect is that the benefit to other users increases with the size of network. While Clubhouse managed to gain a lot of viral traction, the benefit of its network to the users — creators and listeners — didn’t increase with the network’s size.

Specifically, building an audience on Clubhouse is close to impossible. Instead, each creator has to bring their audience with them. However, those audiences gain nothing in terms of convenience when joining Clubhouse, as described above.

Even if creators manage to gain followers on Clubhouse, those followers don’t have much reason to come back because they can’t consume content on demand, and neither they can get content recommendations from Clubhouse. Effectively, Clubhouse placed the burden of curation the listeners themselves.

While Clubhouse recently launched a playback feature, that motion came after a steep decline in popularity, and at this point I don’t believe it will be sufficient to regain the growth momentum.

Switching costs

We often talk about products in terms of switching costs. If you were to leave Spotify, Apple Music, or Netflix, you would have to leave your content, playlists, and a your unique recommendation profile. If you were to leave Facebook, Twitter, or LinkedIn, you would have to leave your communities.

Unlike those examples, the cost of switching from Clubhouse to an alternative is effectively 0, because as a platform Clubhouse failed to facilitate lasting creator <> listener relationships, and thus it failed to offer a sufficiently diverse content discovery experience to the listeners.

In short, if you left Clubhouse as a listener, you lost nothing. If you left Clubhouse as a creator, you also lost nothing because you’d still have your audience elsewhere.

What’s next?

The past 10 years of tech teach us that startups like Clubhouse are too big to die fast. Backed by aggressive venture capital firms and led by monomaniacal founders, such companies don’t easily let go of their dreams to reach massive scales. Instead, they fade slowly until their boards finally decide to cut losses.

Case in point: Path. For those who don’t remember, Path was a social network whose most distinctive feature was that it capped your number of friends at 150. After raising $66M by 2014, or about $77M in today’s money, Path failed to sustain traction. It gained regional popularity in Indonesia and was sold off to Kakao in 2015.

My prediction is that Clubhouse will follow a similar trajectory. It will establish itself as one of the popular niche products in a growing region outside of the US, and by end-2023/2024 it will sell to a more successful local company that sees Clubhouse as a way to augment its product portfolio.

According to multiple media outlets, at it’s peak Clubhouse’s most engaged audiences were in Germany and Japan. Recently, the app has picked up in India, and the country is reportedly becoming a focal point for the company’s leadership (source).

What do you think will happen with Clubhouse? I’d love to read your comments.

Here comes a question, though. If you’ve never hired or managed a product manager before, how do you onboard them and set them for success?

As of 2022, I’ve been working in product for about 8 years. My journey spans startups at different scales and big tech companies. On top of that, I advised several startups on hiring their first PM.

Here I want to share with you a few tips which will help you to empower your first PM to do their best job.

Help your team understand what PMs do

Step one toward onboarding your first product manager happens before they join.

Even though software product management as a discipline has been around for forty years, only in the past decade we’ve seen an exponential growth in the number of jobs and the availability of talent.

Throughout the years, I met plenty of seasoned engineers, designers, sales folks, and operations professionals who have never partnered with a product manager in their life. Chances are, some of your team members have never worked with a PM either.

It falls on you as a founder to help your team understand the role of a product manager and how fits in the organization and in the product development flow. Don’t expect your engineers and designer to know how to work with a PM — and don’t place the burden of explaining that on the new product manager herself.

Instead, aim to bring clarity about the role and to set expectation around how you see the team working with the PM. Some resources that can help you are below.

Resources:

• What, exactly, is a product manager? by Martin Eriksson

• What is product management? by Lenny Rachitsky

• Working with product managers: Advice from PMs, by Gergely Orosz

Give them time to learn

Whether your new PM worked in your industry vertical before or not, you shouldn’t expect them to hit the ground running. Your PM will rely on you to help ease into the reality of your business.

As a hiring manager, you should aim for a 3 months ramp up time, during which your could help the PM onboard. Onboarding here means giving them time and space to build relationships within the team, understand how the founders think and make decisions, and to learn the business.

Resource: Make the first 90 days count, by Deb Liu

Set clear role expectations

A mistake I see happening at startups when they hire their first PM is that the PM is expected to handle everything. It might be tempting to think of a PM as someone who can pick up slack and fill unstructured organizational gaps, but similarly to engineers, product managers need focus.

You should aim for a single-threaded ownership where your PM is responsible for clearly defined product area, at least initially. Even if your hire is senior enough, you can expect them to scale their impact across multiple teams no sooner then after 6 months.

Give up [some] control

Your startup is your baby, and it’s growing up quickly. When this happens, you need to give up the custody to people who can take care of it in your absence: product managers.

It’s safe to assume that as a startup founder, you no longer have the time for operational aspects of product development: hands-on user research, feature validation, and roadmapping. Instead, your focus is on the long term business growth, marketing, fundraising, and sales. And that’s why you’re hiring a product manager.

PMs thrive when they have clear ownership of their area of responsibility — even if they are junior and that area is relatively small. So, once they get on board, you need to make the PM feel that they have full decision making power in the areas you need help with, and actively remove yourself from decision loops.

Resources: Empowered product teams, by Marty Cagan

Pay attention to strategy

Once you hire a PM, it might be tempting to take a deep dive into growth and fundraising, but don’t forget about product and business strategy.

While your PM will help to execute, they don’t know the business and the industry the way you do, and they are not in a position create a full scale product strategy for your company. Strategy is still your responsibility as a founder.

If you implicitly rely on a PM to “figure out” the product strategy, you will create a strategy vacuum. This has serious repercussions: team misalignment, product development delays, building the wrong thing.

Disagree and commit

There will be a time when your PMs will understand the customers and users better than you. They will log more customer calls than you, and will keep hand on the pulse of the market. Inevitably, they will be able to make better decisions about the roadmap — and some of those decisions you will disagree with.

I’m here to remind you that hiring a PM means welcoming them to the discussion table when deciding which customer problems to solve.

Instead of shooting down their ideas, commit.

Further reading

• How to craft your product team at every stage, from pre-product/market fit to hypergrowth, First Round

• Our 6 must reads if you're hiring a product manager, First Round

• How to hire a product manager, Ken Norton