You were always more valuable if you could do both, even pre-AI. Think of early founding team members who had a broad set of capabilities with enough depth to execute. What’s changing now is that this is no longer just an advantage. It is becoming the expectation even within formalized roles at larger companies.

The shift is happening because AI is compressing the distance, both within and between implementation and distribution.

Today, product, design and engineering are closest to the build cycle, while sales, solutions architects, marketing and customer support are closest to the distribution cycle.

AI tools not only reduce the time required for work, they also reduce the skill required for large parts of it.

If you break work down, it has two components:

• Mechanical / procedural skill
• Taste / judgment

AI is getting very good at the first. Which means the second becomes even more valuable.

Let’s make this concrete. Imagine we’re designing how a partially fulfilled order should be handled in a food delivery app.

A customer orders five items. Right before the restaurant confirms, the kitchen marks one item as sold out. The rest of the order is already cooking. The PM has already decided the policy: silently refund or substitute the unavailable item without interrupting the customer.

The designer’s job is to communicate this on the order tracking screen so the customer trusts the change without being alarmed. The work breaks down into two parts.

Mechanical skill: This is what AI tools are already great at with a one-shot prompt.

1. Generate the order tracking screen states showing the removed item, updated total and revised order state.
2. Write the copy: “One item was sold out and refunded. New total: $24.50.”

Judgment skill: This is where domain context and personal point of view matter.

1. Visual weight. It can’t look like an error because nothing actually went wrong. But it also can’t be so quiet that the customer later thinks there was a billing mistake.
2. Show the math vs. just the total. One optimizes for transparency, the other for simplicity.
3. Information hierarchy. The customer opened this screen to check their delivery ETA, not to read a change log. Don’t hijack their attention.

The mechanical implementation not only used to take longer in the pre-AI era, it also required someone who knew design and knew how to use the tools to generate the artefacts. Today, much of that same work can be done by someone with little design knowledge using AI. A PM who was previously a 4/10 in design can now become a 7/10 by letting AI handle the mechanical work. The same idea can be extrapolated across engineering, design and business.

This means a single builder persona becomes much easier to achieve. You can realistically be a 7/10 across multiple disciplines. The game now is how quickly you can climb the judgment ladder in each of them.

But why is selling still different?

If AI is collapsing disciplines within building, why wouldn’t it collapse selling as well? It may well happen eventually, but there’s a reason it hasn’t today.

Going back to first principles, selling is about influencing another human’s emotions and logic. Building, on the other hand, involves working with machines. That distinction is still tangible enough for selling to remain its own skill.

To become more valuable, you’ll increasingly need to do both. Building becomes the baseline. Selling is what compounds it.

It was my first time using Readwise, and it couldn’t do the very first thing I wanted it to do. I gave up pretty quickly. In my head, I was done with it and would probably never have come back.

Then, 3 days later, I get this email.

I hadn’t reached out to support or asked for help. This was proactively sent based on their error logs.

Probably, this what productivity gains with AI could look like?

Some organisations are still struggling to meet basic SLAs on customer support, while others are using signals like these to actively reach out and win back users who have already churned.

I think I might give Readwise another shot!

Positioning is about carving out a unique place in the mind of your buyer so they can clearly choose you over your competitors. It’s how you frame the problem you solve in order to differentiate yourself in a crowded market.

For example, while Figma and Sketch have a highly overlapping feature set, Figma positioned itself as a design tool for teams to collaborate in real time, whereas Sketch positioned itself as a Mac-native app for UI designers.

Similarly, Slack did not position itself as “a faster chat app” or a “messaging app for teams.” Instead, it positioned itself as the app “where work happens,” making it more central to teams and giving it access to a broader market.

In the minds of buyers, Slack was no longer competing with chat apps. It was competing with email as the system of record for work. That positioning:

• Justified deep integrations with tools like Jira, GitHub, and Google Docs
• Encouraged teams to move workflows, not just messages

If Slack had positioned itself as “team chat,” it would have remained a feature, not a platform.

How is positioning different from messaging or copywriting?

A simple mental model:

• Positioning: Why us? Positioning is what actually sticks in the user’s mind after the messaging has been consumed.
• Messaging: What should they understand? Messaging is the set of key ideas you want the user to remember. It is more strategic and changes less frequently compared to copywriting, which is more tactical and iterated on often.
• Copywriting: What exact words do we use here? Copywriting is about how you phrase those ideas to drive action.

Let’s take Slack’s example.

• Positioning: “Where work happens”
  • The idea is to be seen as the central hub for work, not just a chat tool
• Messaging: The themes they keep reinforcing in across all communication channels:
  • Bring your team together
  • Organise conversations into channels
  • Integrate with all your tools
  • Make everything searchable
  • Reduce back-and-forth on email
• Copywriting: How this actually shows up in what you read on the website or on product surfaces:
  • “Made for people. Built for productivity”
  • “Connect your team, align your work, and move faster”
  • “Channels keep conversations organised and accessible”

There are a few areas which I focus on:

• Problem: Getting a clear articulation of the problem that a company is solving.
• Product Bet vs competition: What is the product bet that translates to a business opportunity and why is this company better placed than others?
• Product bet translates to business Outcome: What product outcomes directly impact the topline? Eg. what leads to improved topline - more transactions, more time spent etc.
• Risks current and future: eg. why are customers churning currently or will do so in the future in this market?
• How’s the business doing? What’s the revenue growth, gross margin?

The above is a general framework, and since this is a B2B product, let’s go into some more nuances. For a B2C businesses, it will look a little different, and I’ll cover it in a future post.

So let’s get into Figma’s S1.

Problem

The first question I ask when reading any B2B SaaS S-1 is simple: what product outcome is the company trying to own? Great software doesn’t win because it has more features. It wins because it becomes the default way customers complete an important workflow. Once a product owns the workflow, pricing power, retention and expansion tend to follow naturally.

Design tools were single-player, while product development is inherently multiplayer. Figma primarily solves a coordination problem, and solving for multiplayer was the bet.

Workflow problems (tools people use daily) create habit lock-in. Coordination problems (tools that connect teams) create network-effect lock-in. Data problems (tools that accumulate institutional knowledge) create the deepest lock-in of all.

Product bet

Figma made design feel like Google Docs and made a multiplayer collaborative canvas for design. Instead of the clunky back-and-forth of sending files, getting feedback, and managing versions (like with Sketch), everything happens in one shared file where designers and developers collaborate in real time, and developers can directly grab code without exports. Under the hood, this was powered by some pretty novel bets: using WebGL (2D/3D graphic rendering) and WebAssembly to make the browser perform like a native editor, introducing vector networks for more flexible design workflows, and enabling true multiplayer editing at scale using CRDTs (Conflict-free Replicated Data Types). The browser native bet also aligns with it’s PLG motion because a desktop app would have required an install and an IT approval. A designer could share a Figma link with a developer or a stakeholder, and they could open it instantly. Every share was a product-led acquisition.

The real-time multiplayer nature of the product - when a designer, developer and a PM could see each other’s cursor made the value very clear - no sales team required to pitch that value. The dev mode made it easy for devs to extract CSS measurements and assets, which then became an additional persona who depended on the tool (network effect increasing the switching cost).

Now in 2025, Figma has gone deep and evolved into a full-fledged product development platform, having launched 7 new products in the last 4 years.

Product Bet Translates to Business Outcome

A great product doesn’t automatically become a great business. The bridge between the two is the go-to-market motion and pricing model. Figma operates a hybrid model where product-led growth (PLG) seeds adoption and enterprise sales scale it. Individuals and small teams start on the free Starter or Professional plans, while larger organisations move to Organisation and Enterprise plans that introduce governance, security and administrative controls. The pricing isn’t simply tiered by features; it’s designed to support how customers naturally mature from individual users into enterprise accounts.

The next question is what actually drives expansion. Net Revenue Retention (NRR), which measures how much revenue existing customers generate after accounting for upgrades, downgrades and churn, is one of the best indicators of a SaaS company’s long-term health because it reveals whether growth is coming from customers the company has already acquired. NRR can be driven by seat expansion, tier upgrades, usage or cross-sell, and each has a different level of durability. Figma’s expansion engine is primarily powered by seat growth into new personas and product expansion across the platform. Dev Mode transformed developers into a paid user persona, who now account for roughly 30% of monthly active users, while products like FigJam, Slides, Sites and Buzz have resulted in more than three-quarters of customers using multiple products. One important nuance is that part of today’s 132% NRR also reflects the March 2025 pricing changes, something management already expects to normalise over time. That makes seat expansion and cross-product adoption the metrics worth watching going forward.

Finally, I look for evidence that PLG actually converts into enterprise revenue. Around 70% of new Organisation and Enterprise customers already had someone using the Professional plan before upgrading. That’s one of the clearest indicators that the PLG motion is working. The SMB base isn’t simply generating revenue in its own right, it’s continuously feeding the enterprise pipeline. There is, however, an interesting trade-off. The recent pricing changes introduced administrator approval before additional seats are provisioned, replacing the previous user-led upgrade flow. While this improves governance for larger organisations, it also introduces friction into the very expansion engine that made the bottoms-up strategy so effective.

Risks: Current and Future

When evaluating risks, I separate them into three categories: structural churn, expansion risk and technology disruption. Starting with churn, Figma’s reported 96% Gross Revenue Retention (GRR), which measures how much recurring revenue is retained from existing customers before expansion. That suggests enterprise customers remain exceptionally sticky, while the inevitable churn within the SMB base is largely hidden from the headline metric. For a company built on PLG, that’s not necessarily concerning, but it does mean retention should always be interpreted in the context of customer segments rather than as a single blended number.

The more interesting risk is expansion drag. A SaaS business can retain customers while still slowing materially if existing accounts stop growing. Figma’s shift to administrator approval for seat upgrades is the clearest example of this. Previously, users could add seats immediately, with administrators reviewing them after the fact. Now, every additional seat requires approval before it’s provisioned. It’s a subtle operational change, but strategically it places procurement in front of what was previously a product-led expansion motion. If approval rates slow or organisations become more disciplined on licensing, seat-based expansion could naturally moderate over time.

AI creates a different category of risk altogether. Rather than asking whether AI is a threat, it’s more useful to ask how it changes the workflow Figma owns. AI-generated interfaces could automate parts of the design process, reducing the amount of traditional design work required. At the same time, Figma’s own AI capabilities can make designers more productive and strengthen the platform. A third possibility is that entirely new workflows emerge through tools like Cursor or v0, allowing software teams to move from idea to implementation with less dependence on traditional design tools. These are fundamentally different risks, and Figma will likely need a different strategy to address each of them.

How’s the Business Doing?

The first metrics I look at are Gross Revenue Retention (GRR), which measures how much recurring revenue a company retains from existing customers before expansion, and Net Revenue Retention (NRR), which includes expansion revenue from those same customers. Together, they tell you whether customers are staying and whether they’re growing. Figma’s 96% GRR shows that enterprise customers rarely leave, while its 132% NRR demonstrates that existing customers continue increasing their spend.

The customer distribution provides another useful lens. Figma has roughly 450,000 paying customers, over 11,000 spending more than $10,000 annually, and just over 1,000 spending more than $100,000 annually. At the same time, 95% of the Fortune 500 already uses the platform. That gap between widespread adoption and relatively modest enterprise monetisation represents one of the company’s biggest opportunities. Much of the future growth story is likely to come from converting existing usage into larger enterprise relationships rather than acquiring entirely new customers.

Revenue grew 48% in 2024 and continued growing 46% year over year in Q1 2025, while non-GAAP operating margins improved from 5% in 2023 to 17% in 2024. Combined with gross margins above 90%, efficient customer acquisition and strong expansion, this suggests the business is moving beyond pure growth mode into a phase where scale is beginning to generate operating leverage. Although Figma doesn’t disclose its CAC payback period directly, its combination of 90%+ gross margins, 132% NRR and a product-led sales motion suggests a very efficient payback profile.

All of this culminates in one of the simplest but most powerful SaaS metrics: the Rule of 40, calculated as revenue growth rate + profitability margin (typically operating margin or free cash flow margin). A score above 40 is generally considered the benchmark for a healthy public SaaS company. Using Figma’s 2024 results, the calculation is straightforward: 48% revenue growth + 17% non-GAAP operating margin = 65, comfortably above the threshold. More importantly, Figma achieves this without sacrificing growth.

Recently came across this one while listening to the Acquired episode on Visa. Visa and the NFL are similar in heir ownership structure. Both are essentially the opposite of a traditional holding company, more like a “reverse holding company.”

The NFL league office does not own the teams. Instead, the 32 individual team owners collectively own the NFL. Similarly, Visa was created in 1968 by Dee Hock as a non-stock membership corporation. He convinced ~200 banks to own the network in proportion to the transaction volume they contributed. In return, they all agreed to operate under Visa’s singular set of operating and governing procedures.

And “convinced” is the key word here. These banks were competing intensely for the same customers and merchants. For some of the larger banks, not joining could mean owning a bigger piece of a smaller pie, versus a smaller piece of a much larger future pie.

Dee Hock was exceptional at persuasion and debate, appealing not just to logic but also to emotion. That’s a story for another day.

In 2024, Google I/O was buzzing with AI, AI and AI. This time it was almost the same, but the focus was largely on models. Faster models, better performing models, cost efficient models. You can pull knobs in any direction to suit your need.

The big positive this year was seeing real world applications of the research investments announced in 2024. AI research is now starting to show up in usable products. Still, it feels early days for most consumer adoption. Developer products are where the real disruption has started, with Gemini claiming to be the fastest growing model across coding tools. Jules is there for coding too, but not sure yet what the real play is.

Consumer products are seeing a shift in user behaviour:

• Google Search: AI overviews are driving more queries. At first that feels counterintuitive. If a search product does its job well, you should only need to search once. But curiosity pushes you deeper, and you end up searching more. I think that is mostly the case, which is why it was seen as a positive signal.
• AI mode in Search: essentially a chat version of search. Not clear how this will differ from Gemini. The bigger question is how long before it becomes default, since that could hit the bottom line without an ads model on top.

Some of the future products felt almost unreal:

1. Google Beam for 3D video calling. A hardware product with six cameras stitching videos into a 3D view. Futuristic, but not really AI. Likely an enterprise use-case unless it can be baked into a TV screen.
2. Personalisation across the platform: smarter email replies using past emails, Gemini app tying into Drive and Calendar for suggestions, and search tuned to your own habits (eg. you like rooftop bars, so the next time you search “restaurants near me”, you get your preferences on top).
3. Universal AI Assistant - to me, this could be the real game-changer. Powered through “world models”, with the ability to take action on everyday tasks. Summarising a YouTube video, making a table reservation, answering queries. The promise is big, but the risk is - it goes the Siri way, with demos that look impressive but never land in everyday use.
4. Real time speech translation that mimics voice, tone and expressions.
5. Gemini Live Search with camera and screen sharing.

In a world where models will eventually feel commoditised, Google’s real play is embedding intelligence into products that already have massive distribution. That is their moat. The big question is whether it’s an effective one or not. Do these demos translate into reliable capabilities that work across edge cases and actually get adopted and retained by users? If I want to book a table at my favourite restaurant and seven times out of ten it needs my intervention, I would rather just do it myself. Models will keep improving, but the bar is whether they can handle enough of these edge cases to feel dependable.

It almost feels like Google was pushed into bringing these products out earlier than planned to keep pace with the market because some of their new products lack that polish. Those initial bumps may be necessary since they create the real-world data that models need to become truly reliable. And if data from those feedback loops is what separates flashy demos from real capabilities, Google is better positioned than most to close that gap given their distribution. That’s the bull case for Google - leverage existing distribution to either launch completely new products or make existing products more useful and reliable. User experience is where the competition will play out.

“Gemini is pretty good at telling you when you are wrong,” Sundar Pichai, taking a jab at ChatGPT.

I spent 5 years building for millions of users at Gojek. Delivery flows, marketplace ordering, three-sided coordination at scale. The feedback loops were fast, the users largely homogeneous and the data was plentiful. Then I joined Snyk, a developer security platform, and almost every instinct I had about product needed adjusting.

The fundamentals still held. Good discovery, clear prioritisation, tight feedback loops. But the environment they operate in is structurally different in B2B, and if you do not recognise that early, you end up applying the wrong muscle at the wrong moment. Here is what I wish I had it mapped out earlier.

Economics

The product is shaped by the business model

In B2B, because deal sizes are large, manually intensive processes can be economically justifiable.At Snyk, we have a professional services team and solution engineers who often write custom onboarding scripts. We also have a dedicated Jump Start programme that helps enterprise customers deploy successfully. Custom work often replaces onboarding features because the unit economics support it.

B2C works very differently. Products are priced per transaction or through subscription tiers. If the product does not work out of the box, users churn within days, and you see it in your metrics almost immediately. That tight feedback loop is valuable, but low individual transaction values also mean every process has to scale without human intervention.

You cannot afford bespoke onboarding. The product has to carry the full weight of adoption itself.

Discovery

The hardest part is finding the real problem

In B2C, signals are mostly direct. Customer support tickets, app reviews, and product analytics all come straight from users. They are noisy, but they are close to reality. In B2B, most signals are mediated. They come through account managers, customer success managers, and commercial teams. Each person has already interpreted the original problem through their own lens. By the time feedback reaches Product, it is often a proposed solution rather than the underlying need. Your job is to reverse engineer back to the actual problem.

There is another layer on top of this. The person buying the product is often different from the person using it. For an application security platform, the buying committee might include a CISO or CIO who owns the budget, while the day-to-day users are developers. The buyer wants governance, visibility, and control. The developer wants to ship quickly without interruptions. If you only listen to one side, you will optimise the product in ways that frustrate the other.

Validation also looks very different. In B2C, you can launch a fake door test, collect tens of thousands of data points within hours, and reach statistical significance in days. In B2B, you rarely have enough volume to do that. Your qualitative research has to be significantly stronger because experimentation is often not an option.

Finally, churn is a much slower signal. A customer on a three-year enterprise contract will not disappear overnight. Product issues often surface first in renewal conversations, months before they appear in your dashboards. In B2C, the numbers tell you when something is wrong. In B2B, you have to go looking for it.

The PM implication is that discovery in B2B requires two separate tracks: one for buyers and one for users. Treat feedback from commercial teams as a hypothesis to validate, not a solution to implement.

Prioritisation

Every roadmap is a series of trade-offs

Two people ordering food on a delivery app differ along a handful of dimensions: price sensitivity, cuisine preference, and how quickly they want their meal. Two enterprise software customers can differ across industry, compliance requirements, internal tooling, team structure, and security maturity. One customer may need APIs to build internal workflows and granular permissions for hundreds of users. Another simply wants sensible defaults and a smooth rollout. This is why finding your ICP matters so much. The noisiest customers are often the ones your product fits the least. Trying to serve everyone eventually leaves you with a fragmented customer base and a roadmap that serves nobody particularly well.

At the same time, every B2B PM quickly learns that there are really two roadmaps: the one Product planned and the one Sales brings you in real time. That is not dysfunction. It is how enterprise software works. The same applies to escalations. When a large deal is at stake, enterprise sales teams do exactly what they are hired to do: escalate to leadership when Product says no to a customer request. At Snyk, we once built a capability much earlier than planned, and perhaps one we would never have built otherwise, because it helped secure a strategically important enterprise customer. Adoption remained low, but the commercial outcome justified the decision.

Your role as a PM is not to resist these requests. It is to make the trade-offs explicit. Building this custom API means delaying the Q3 release by six weeks. Once those trade-offs are visible, leadership owns the decision rather than implicitly handing it back to Product. Know your ICP precisely and build for the customers your product is designed to serve, not simply the ones making the most noise.

Launch

Shipping the feature is only half the job

In B2C, you can quietly release a feature to 5% of users, monitor the metrics, and either expand the rollout or pull it back. Marketing usually becomes involved close to launch. In B2B, launches begin much earlier. Before a beta reaches a single customer, sales needs to know how to position it, account managers need to know what to tell existing customers, and marketing needs a story that resonates with both decision-makers and end users. Positioning matters because enterprise buying decisions involve multiple stakeholders with different priorities. Internal enablement is therefore not a nice-to-have. It is part of the product. A feature that is technically live but that nobody in Sales can confidently explain is, in practice, not launched. Legal and compliance also become key stakeholders in ways they rarely do in B2C. This is particularly true in AI, where implementation choices around data storage, processing, and model usage can become contractual blockers rather than technical details.

The implication for a PM is that you need to budget time for internal coordination throughout the rollout, from validation to different phases of availability. Sales enablement, internal documentation, FAQs, positioning are all part of shipping the product.

Today’s a lot of engineering problems have multiple tools, often robust open source alternatives exist. Cloud infrastructure makes migrations easier so the trend is in favour of switching costs which are increasingly coming down or non-existent for some cases. Human attention, on the other hand, is a scarce resource, much like compute power these days.

Take the example of Stripe which entered the payments market with their famous 7-line integration which was concise but also complete. Test mode, live mode, error handling, webhook setup. Developers could copy, modify, and have a working integration and reach their Aha moment in a few minutes. Even though it didn’t have the most comprehensive feature set. What they had was an integration experience that took minutes instead of weeks. They weren’t first. They weren’t cheapest. And this initial experience triggered a cascade.. word of mouth spread, blog posts appeared, conference talks referenced this as an example of “how APIs should work.” and over time Stripe has built a benchmark in DX.

Some other examples - Vercel’s deployment experience. Tailwind’s documentation. Supabase’s onboarding. Made them grow quickly because it impressed developers who then would spread out the word - productivity brag! But that’s just the entry point. The real difference shows up when companies keep creating these word-of-mouth-worthy experiences across the rest of the product. That’s what actually drives long-term retention. And that’s where DX starts turning into a moat.

This matters even more now with AI. When every tool can spin up a decent baseline experience, that just becomes the table stakes. So in a world where building SaaS is getting cheaper and faster, UX isn’t just how you enter a market anymore (like Stripe or Linear did), it’s also how you keep users around.

It becomes a moat because it’s genuinely hard to do consistently. It shows up in the small decisions. It takes years. Most users won’t consciously notice it, but they’ll feel it. And it requires clear principles guiding thousands of tiny decisions across the product.

And those decisions only work when product, engineering, go-to-market, DevRel, support and all other functions are pulling in the same direction. Not just for one launch, but over years. Most companies struggle with this because scaled coordination is hard and incentives don’t always line up.

The first is simple, and easy to ignore: take full responsibility for everything in your life. Nothing changes until you own the outcome; not just the parts that went well.

Most people don’t fail because they lack motivation. They fail because intensity feels productive while consistency actually is. A two-week sprint rarely beats showing up every day for two years. Focus on one thing at a time. Give 100% to one goal instead of 20% to five. Make gradual improvements — you can’t jump to level 10 with level 1 habits. Read one page. Write one paragraph. Meet the deadlines you set. Find someone who will hold you to them.

You also don’t need to be the best in the world at one skill. You need a rare combination of a few. Scott Adams, the creator of Dilbert, explained this well:

In my case, I can draw better than most people, but I’m hardly an artist. And I’m not any funnier than the average standup comedian who never makes it big, but I’m funnier than most people. The magic is that few people can draw well and write jokes. It’s the combination of the two that makes what I do so rare. And when you add in my business background, suddenly I had a topic that few cartoonists could hope to understand without living it.

The goal isn’t to be top 1% at everything. It’s to be in the top 25% at two or three things that matter — and stack them together into something hard to copy. Genius, in that sense, isn’t about extraordinary intelligence. It’s about being extremely good at a couple of things that really matter, and not being afraid to do work that feels out of reach. The idea of “intelligence” gets in the way. However smart you are, someone else is smarter. You don’t need to win that comparison.

Purpose helps tie it together. It’s hard to live a fulfilled life without direction or a clear plan. Once you know what you’re working towards, everything else becomes a little clearer.

Most of these ideas are simple. The hard part is living them consistently.

On the other hand, a bad and successful product solves a problem but only partially or inefficiently and doesn’t deliver a delightful experience. As a user, one doesn’t feel like coming back but would still need to come back since there is nothing better out there in the market to solve their problem. Or there might be some other products which are just marginally better from the existing solution and the friction to adopt them is just too high for users to switch.

Diving a bit deeper into some of the aspects of “bad and successful” products:

• “**Good” or “Bad” depends on the user segment” - what may be a bad product for one user may be a good product for another user.
• “**Bad” but only from a specific aspect” - I wouldn’t call these “bad products” as they do solve a problem fully but they are viewed as poor in a certain aspect:
  • poorly designed - Jira, Tally, Amazon
  • poorly modelled business - Blockbuster’s majority revenue came from charging late fees to customers. One can’t have a sustainable longer-term model built out of making users feel bad, hence I would term this as a poor business model

How do bad products become successful?

When a problem is solved partially by a product but users still continue using it because of the lack of any other alternative way to solve their problem fully, these products start becoming successful. I’ll call these successful “businesses” rather (most cases earning revenue and profit) but not successful products as the vast majority of users feel little value and still hesitatingly continue to pay for this value. Example: subscription based dating apps where you’d pay if you still haven’t derived the value from the product i.e you are still paying because you still haven’t been able to go on a good date. You’d stop paying if you were no longer single and dating someone.

How do good products turning bad (intentionally or unintentionally) for a particular segment?

It might be the case that a product is no longer a great experience for some part of the user segment i.e product market fit (PMF) has degraded for this segment but the product still delivers value to another user segment. These are still successful products since they deliver value to a decently sized segment if not the majority of the TAM. PMF degrades over time for a certain user segment because of 2 reasons -

1. The product evolved in a way that focussed on one specific segment. Example: Adobe photoshop over-optimized for power users and is now a professional segment targeted product which meant PMF was lost for the amateur segment. So, it’s a poor product for the amateur segment where now Figma and Canva play.
2. The user segment has evolved and has different needs now which can’t be met with the existing product Example: for Facebook, users who join in their 20s might want to connect with >100s of friends but as users grow older, they might prefer a close network of ~20 friends. Also, lots of features that address very specific needs of a niche user segment have gotten added to FB over time which may make the app feel clunky to the remaining population (FB fundraisers, FB blood donation, FB jobs are features which are not so mainstream). Hence, it might be seen as a relatively poorer product for users who were used to the neat and light experience, however it still continues to run strongly for newer users. This would also reflect in their retention cohorts.