Tag: Product Management

AI Musings #4 – How To Differentiate As An AI Applications Startup?

Discussing two areas startups can focus on to create competitive differentiation in the AI applications layer – (1) data and (2) product flows.

Over the last few weeks, I have met a few exciting startups building in the applications layer of AI. As the landscape stands today, the foundational LLMs layer is likely to be dominated by a mix of open-source, Big Tech, and perhaps 1-2 hyper scalers (eg. Anthropic). The cloud infra (compute, safety, security etc.) to deliver these model capabilities will definitely be served by the Big Tech cloud players.

This leaves 2 categories for startups to exploit against these large competitors – (1) Applications and (2) Dev Tools. On the latter, I don’t understand it deeply enough to have a view on it (yet). However, the Application layer is something I get, and therefore, have some working POVs on it.

Almost all AI application layer startups I am seeing right now are essentially using ChatGPT (+ Bard and Llama in a few cases) to build features that solve sharp use cases in specific verticals. Based on observation, some low-hanging verticals that founders are going after include Insurance, Marketing, Sales, and HRTech with AI-generated content being a horizontal ingredient in most of these products (eg. automated email generation, stitching together a marketing video, crafting a training course outline etc.).

In all these cases, I am still struggling to understand how these startups can create competitive differentiation or moats purely by building features on top of hyper-scaler APIs. To take a step back:

For a new technology inflection to create viable startup opportunities, there need to be sizable areas where new companies are significantly better positioned than incumbents to leverage this new technology and solve unaddressed customer problems.

This is a really important point. For a startup to be viable, it’s not enough to just be an early adopter of cool technology and build new products before anyone else. The startup has to be able to create significant differentiation against entrenched competition too. Eg. Apple beat IBM in the PC inflection, Amazon beat offline retailers in the Internet inflection, Instagram and WhatsApp beat Facebook in the mobile inflection, and Figma beat AdobeXD in the cloud inflection.

This is the aspect where I am pushing all AI application founders I meet to start thinking through and strategizing from Day 0. A couple of ways to potentially drive competitive differentiation have emerged from these working sessions:

1/ Access to data

While ChatGPT is great for bootstrapping specific use cases, eventual product differentiation will emerge from startups fine-tuning their own LLMs (with open-source models as a starting point) using proprietary data sets for industry-specific use cases.

To put it simply, foundational models will keep doing a great job of adding horizontal knowledge. Startups will need to do the work of incorporating deep vertical knowledge into the models.

Here, access to the ‘right’ customer data will be critical. But then, entrenched incumbents would already have access to much more data than a 0-to-1 startup. So, how does a startup create a data advantage?

One way could be to identify unsolved pain points for customers that large pre-AI competitors aren’t going after, either because they are contextually unviable (Innovator’s Dilemma), were unsolvable pre-AI, or due to organizational inertia.

In these cases, AI-native startups can leverage their speed to get to the ‘right’ customer data sets before anyone else, and start creating an edge via custom fine-tuning and benefiting from faster learning cycles.

It’s interesting that the underlying driver of this differentiation is still good-old startup execution, rather than just building AI-first features. The company would still require classic software execution (founder-led sales, figuring out ICP, setting up GTM motions, etc.) to succeed.

2/ New product flows

Another area where startups could do better than the entrenched competition is putting in the work to develop AI-first product flows. We saw this happen in previous tech inflections where new capabilities and form factors gave rise to new ways of doing specific jobs. Eg. Apple cracked the smartphone user experience while Nokia struggled. Or Figma figured out how designers should work and collaborate with other functions in a fully hosted, in-browser experience, while Adobe continued to be stuck in its old UX.

Given the vast range of new capabilities that AI is unlocking (eg. chat-based UX, AI ‘agents’ to deliver specific tasks that underly use cases), it’s reasonable to expect a plethora of new workflows to emerge across customer segments. Many of them will require absolutely fresh product thinking to crack, something that pre-AI product teams at established companies might struggle with.

Similar to the ‘access to data’ point earlier, the underlying driver of this product flows differentiation again will be good-old, startup-style product management – Paul Graham’s “do things that don’t scale”, starting with a wedge of focusing on a very-specific customer persona and pain point, frantically iterating on it, and in the words of Brian Chesky, “Focusing on 100 people that love you, rather than getting a million people to kind of like you”.

Putting things together…

If one looks at both the above areas of potential startup differentiation, the way AI might end up creating viable startup opportunities is not the LLM technology itself, which will become baseline, widely available (like cloud today), and likely open source (similar to programming languages like Java and Python).

Rather, the drivers of value creation by startups will be in:

(1) What’s needed to effectively leverage these LLMs to solve verticalized, deep industry-specific problems – eg. pre-AI, a 10x backend engineer was needed to leverage the cloud. Post AI, specific datasets will be needed to leverage LLMs.

(2) 2nd and 3rd order impact of AI on product experiences and workflows – Figma and Notion took years of fresh thinking and iterations to reimagine collaboration UX in the cloud. AI-first use cases will require similar untethered, ground-up product thinking to deliver these capabilities effectively to customers.

What does this mean for venture investing?

It means even in the post-AI world, investors should continue to look for founding teams that demonstrate many of the classical startup traits, a few of them being – (1) ability to unearth a unique customer insight, (2) product thinking to be able to solve for it, (3) GTM skillset to be able to create a differentiated business out of it, and (4) grit to last through the journey.

Essentially, might be a good idea to avoid AI overthink and keep doing more of the basics of venture capital.

Note: check out the previous post #3 in this AI Musings series – LLMs for Beginners.

Subscribe

to my weekly newsletter where in addition to my long-form posts, I will also share a weekly recap of all my social posts & writings, what I loved to read & watch that week + other useful insights & analysis exclusively for my subscribers.

SMB SaaS at Scale: Founder Learnings from HubSpot

SMB SaaS is hard. Getting the positioning right, increasing ACVs, controlling churn – it all becomes harder when your customer is a small business that is resource constrained & perpetually dealing with its own execution challenges.

Despite this, given SMBs are the most frequent early adopters of new products, the reality is that most startups tend to start mid-market. Though, in my experience, a majority get stuck in unfavorable economics of this customer segment & are unable to achieve breakout PMF.

So, what is the secret sauce founders can learn to effectively scale SMB SaaS? Hubspot is a great case study. I recently came across this SaaStr podcast with the HubSpot CEO Yamini Rangan, where she shared some of the company’s SMB strategy & learnings. Here are the key highlights:

  1. Go after a large TAM: given the fragmented nature of SMB verticals, it’s really important to have a large TAM. HubSpot made the smart decision to transition from marketing automation to CRMs, basically going after Salesforces’s lunch.

Mid-market verticals tend to have open opportunities for startups as SMB customers are usually sandwiched between either buying a host of solutions & stitching them together or buying an expensive, enterprise-grade solution. In this context, I had recently posted a Twitter thread about how Zoho followed a similar multi-use case bundling strategy to position itself as an “operating system for SMBs”. This strategy works well as SMBs have a tendency to simplify their tech stack & procurement processes by buying multiple solutions from the same vendor.

2. Customers gravitate towards competitively-priced, mission-critical products: in times of economic uncertainty like today, SMBs tend to become really sensitive about budgets. Customers start asking tough questions internally around (1) where are they spending?, (2) do they have a clear path to getting enough value from the spend? and (3) can they do more with less?

Acting per this analysis, SMB customers are then likely to consolidate their tech stack to a handful of mission-critical platforms that are competitively priced & deliver the most value. This is the bar startup products need to cross while selling in this tough macro environment.

3. PLG-based distribution is king: to achieve break-out growth in SMB SaaS products, startups need to have the widest possible distribution. The front door needs to be big enough so that most people can come in.

For the first 8-9 years, HubSpot was mainly driven by a sales motion comprising Direct Sales & Partner Sales. Around 2016-17, in order to exponentially grow distribution, the founders made a counter-intuitive bet to go from sales motion to product motion. Today, HubSpot has a massive user base of ~1Mn WAUs to monetize off of.

4. A strong “free” product is key to PLG: One of HubSpot’s truly differentiated product strategies has been to offer a strong, full-featured free product. Rather than making a “free” product free just for the sake of it, they have focused on making it really valuable.

Some important benefits of having a strong “free” plan:

  • Drives high top-of-funnel growth & user engagement, improving the probability of monetization once the value is proven out.
  • Puts product org. under pressure to deliver enough features at the top, in order to maintain the competitiveness of paid versions.
  • Forces the product team to maintain a “consumerized” ease of use, which benefits all customers, free or paid.

Irrespective of whether your GTM is sales-led or PLG-led, a founder should never give up on the “free” plan as it’s key to keeping your product competitive.

5. North Star Metric should be Net Revenue Retention: NRR is the best health indicator of an SMB SaaS business given it represents whether or not: (1) you are retaining the customer, (2) you are continuing to drive enough value so they buy more from you and (3) you are protecting yourself from churn.

6. Don’t underestimate the value of a Partner ecosystem: once you reach a certain scale, PLG & Direct sales aren’t enough. A thriving partner ecosystem can be a strong GTM moat. Interestingly, a majority of HubSpot solution partners *only* sell & deploy HubSpot as a CRM, thus creating valuable network effects for the company.

7. In geo-expansion, less is better: PLG-driven companies will always have customers in many countries eg. Hubspot has 130+. But in order to deeply localize for elements like language, currency, customer support etc., it’s important to focus only on a few markets. As an example, HubSpot has chosen 7-8 markets to deeply localize their offerings in, based on factors like TAM, existing installed base, net ARR growth being seen & the company’s ability to serve the market locally.

While SMB SaaS can be a tricky business model, it compounds beautifully once the founders figure out its key levers, as HubSpot has shown.

PS: if you enjoyed this post, you might also find this post on Top 10 enterprise SaaS learnings from a unicorn founder helpful.

Subscribe

to my weekly newsletter where in addition to my long-form posts, I will also share a weekly recap of all my social posts & writings, what I loved to read & watch that week + other useful insights & analysis exclusively for my subscribers.

Building…one at a time

I recently tweeted a really interesting insight I heard from Mike Maples, Jr of Floodgate at a recent Draper University closed-door event:

This is so true, and a common mistake that founders & product leaders make while building new products. Looking back on my own startup, while I rigorously tried to execute Paul Graham’s “Do things that don’t scale” philosophy, I still created unreasonable expectations in my own head around user growth for each MVP iteration. This was probably due to the baggage I was carrying from my previous experience of working at large companies like Alibaba, where numbers were talked about in Millions & sometimes, Billions.

When the absolute user numbers weren’t met, my morale as a founder would get hit with each iteration. In hindsight, hitting numbers shouldn’t have been the goal at all. The ideal 0-to-1 mindset is like that of a scientist, with curiosity being the core driving emotion, backed by an iterative product development approach. The target outcome of this approach should be to gather insights that help refine the hypothesis.

Similar to how scientists drive their research process one experiment at a time, I have realized that building any new product or service from grounds-up requires moving one “unit” at a time. It’s up to you to decide what that unit should be – acquisition, activation, frequency of use, revenue or even just getting qualitative feedback!

In a scientific process, more than just the number of experiments run, what’s important is taking the learning from each experiment & applying it to the next one so it becomes better than the first.

Similarly, a good approach to building anything new is to delight one person at a time. This automatically focuses the building process & anchors it on an actual customer, thus making it easier to ship something that solves a monetizable problem for someone in the real world. Trust me, this is a non-trivial hurdle that many startup teams are unable to cross.

The 0-to-1 stage can be highly fuzzy but breaking it down into one unit at a time helps give more clarity to the team around the exact short-term goals.

The most profitable way for a product to grow is via word-of-mouth. The above approach naturally optimizes for it. And once the testimonials & organic growth start kicking in, traction compounds with minimal incremental effort.

Of course, the key to executing this building approach well is patience. Again, think of a scientist. A larger research budget or more headcount can’t necessarily speed up a breakthrough. Similarly, building one unit at a time requires a small team committed to iterating over a long enough timeline for customer compounding to kick in. A lean & capital-efficient operating model is a requirement of this approach as a long runway significantly improves the odds of success.

Learning from my mistakes as a founder, as I have now started working towards regularly putting useful startup & investing content out there, I am consciously following the approach of publishing & learning one unit of content at a time – blog post, Twitter thread, LinkedIn post etc.

Same for my angel investing, wherein I am trying to help each founder, co-investor & startup employee I meet, one week at a time, with whatever resources I have – network, expertise, capital etc.

This approach is helping me to first put the core enablers of my venture investing craft in place that then, hopefully, self-compound. Therefore, I feel much better this time about hitting my long-term goals.

PS: on a similar note, I really like this post by a16z on how creators only need 100 true fans to build a business. Whether this number is 100 or 1,000 is less important. The real insight is that even a small number of dedicated fans are needle-moving.

Also, in case you are interested in other similar startup insights shared by Mike Maples at the DraperU event I referred to earlier, check out my Twitter thread on it.

Subscribe

to my weekly newsletter where in addition to my long-form posts, I will also share a weekly recap of all my social posts & writings, what I loved to read & watch that week + other useful insights & analysis exclusively for my subscribers.

‘Product-First’ approach to building companies

Recently, David Sacks shared about having a product-first approach to building companies, drawing on how Square & PayPal used similar strategies to identify market gaps & solve for them. Here are the key takeaways:

#1 Make a simple product with a clear “hook” to grab users. Typically, this hook is a high-frequency task that users can do in the product to engage with it and subsequently, can then be enticed to engage with other features in the stack. Square -> Swipe, PayPal ->Email Money.

#2 Couple the product hook with a distribution trick that can create viral adoption of the product. Square ->distinctive hardware design & branding. PayPal -> email virality via sending money.

#3 Hook+Distribution trick together hopefully drive enough early users to start learning from. Unique market insight doesn’t appear via a brain wave from founders. It’s identified via observing who is using the product & why. Eg. Square -> merchants not having a credit history.

#4 Build the operating capabilities necessary to execute on this insight. For instance, both Square and PayPal had to build new types of fraud detection systems to solve the lack of credit history & processes. These operating capabilities & IP, turn, become long term moats.

#5 Finally, in this process of operationalizing the market insight, an overarching business theme will emerge. Eg. for Square, it became “access”. Start building out your product roadmap around this theme, and keep adding more offerings but all centered around this “North Star”.

To summarize, getting a unique market insight to build a startup on, first requires launching a simple product that gets user-adoption, observing who they are and why they are using it, and then extrapolating that to re-frame the true pain point of the user.

Building a product to solve for this “reframed” user problem will automatically result in a truly differentiated product that is filling a key gap in the market that few others are seeing in the way you are seeing.

You can read the complete article on David’s substack here.

Note: this post first appeared on the Workomo blog here.

Smarter engineering decisions in startups

Team Workomo had an excellent working session on engineering last week with Prashanth Susarla, ex-CTO of PayU. He shared several frameworks and heuristics with us for taking smarter tech decisions as a really early-stage startup. Sharing key insights below 🎯

#1 Less is more: proactively look for platform elements where you can avoid coding and offload to off-the-shelf services. Look for opportunities where you can cut down your own code. Avoid unnecessarily complex approaches for low-value tasks 🤺

#2 Invest in automated testing: it will yield valuable dividends compared to manual testing. In fact, engineering teams should invest in automated testing ASAP else it becomes part of a broken culture that’s tough to change later ⚙️

#3 Testing is strategic to the product: often teams tend to view testing as low-value ops. Being able to design great test cases is a high-value skill. Break down the most critical user journeys and start automating them. Don’t sweat over perfecting the testing frameworks yet 🛠

#4 Aim for architecture reliability, not perfection: at really early stages, with rapid product iterations and pivots, engineering teams need to build for progress and not perfection. Having said that, keep periodically stress testing your backend for expected traction loads 🏋🏼‍♀️

#5 Define engineering SLAs via highly-specific user stories: eg. a user story could be “95th percentile of my users should not see more than a 5 min delay between updating their Gsuite calendar vs those changes reflecting in the Workomo panel” 🎥

#6 Apply ML to project future loads & requirements: while engineering is building for high-velocity weekly/ biweekly releases, certain core elements require thinking through requirements say after 1–1.5 yrs. However, you can’t build for it right now. So use ML to break down the problem and optimize 🔬

#7 Account for engineering activities in product sprints: core engineering tasks that aren’t always directly related to a specific feature release, still need to be baked into sprint planning & timelines. Helps balance prioritization between feature releases and tech debt optimization ⛹🏽‍♀️

#8 Build a strong engineering culture: that happens as a result of adopting strong habits. A bad habit will often give you speed but destroy value in the long run. Even if you are moving in bi-weekly sprints, always have a 3-month view and a 1-year strategy in place ⏳

#9 Security is important even for a really early product: your platform coming under attack is not a question of “if”, it’s a question of “when”. Think about security as soon as you launch, even in private beta. Imagine a doomsday scenario once a month and prepare for it 🏹

#10 Finally, the best engineering teams are driven by humility: while looking to build any feature or platform, teams need to be incredibly honest to themselves about their present capabilities, what risks can they take, what plans can they pull off & take decisions accordingly 🧗🏽‍♀️

What are some engineering best practices that have worked for you in an early startup environment? Would love to hear your thoughts.

Note: this post first appeared on the Workomo blog here.

Game design playbook for products

Recently came across an amazing talk by Rahul Vohra on how to incorporate game design principles in any software product (Superhuman has, of course, nailed this). Sharing my notes from it below:

#1 Similar to how games have levels & rewards that create instant gratification, create in-product goals for the user that are concrete, achievable & rewarding. For instance, the #inboxZero goal that Superhuman sets for users. Goals take any product beyond just utility & make it fun 🎯

#2 Design for nuanced emotion. Product value needs to be defined beyond just tangible jobs-to-be-done, to include “how it makes the user feel”. Emotions like joy, pride, achievement, trust, fun! Eg. showing a serene pic 🏞 to the user on achieving the in-product goal.

#3 Similar to how games have complex control sequences that are fun to master and expand the game’s potential, software products too, can have rapid & robust controls that match the user’s context of multi-tasking & expecting instant gratification. Eg. smart keyboard shortcuts 🎮

#4 Introduce toys that increase the fun quotient and incent users to spend more time with the product, while also strongly gelling with core features and enhancing value delivery. Eg. fun universal search bar with surprising auto-suggest elements 🔍

#5 Help the user get zoned into the product experience to create extraordinary engagement (almost a “flow” state💻) by making each next step obvious and minimizing energy to be spent in any sort of decision-making. Eg on archiving, moving the user to the next message in milliseconds 🚴🏼‍♀️

#6 Continuing the objective of creating an in-product “flow” state for users, giving clear and immediate feedback to users with no distraction ⛷

#7 Final strategy for creating a “flow” state within the product is to introduce certain challenging skills and make it a little hard for users to master them. Overcoming challenges create dopamine, a feeling of achievement within the user. That feeling will stick with users for a long, long time 🧗🏽‍♀️

Finally, these game design principles need to be executed within the wrapper of your product’s core design language. This includes design principles that you have specifically chosen like say, minimalism, full screen to minimize distractions, there when you need & away when you don’t, etc.

If I have to summarize my overall takeaway — in this era where any software is cheap to replicate, products can stand out by designing for what emotions your target users will feel as they use the product. And making it fun!

PS: Suhas Motwani, great job in organizing this session!

Note: this article first appeared on the Workomo blog here.

Product Management Cheat Sheet for “0-to-1”

Recently came across this awesome podcast by Hiten Shah wherein he shares really practical and execution-oriented insights on building products from 0-to-1. Here are my top 10 takeaways:

  1. Framework for evaluating whether the “problem to be solved” is worth solving — is it 1) frequent enough, 2) painful enough and 3) urgent enough?
  2. An upfront filter he used to evaluate potential startup ideas — building a product that “every human being that’s connected to the Internet would need to use”.
  3. “Ideas are just solutions to problems”. As most founders start with an idea, it’s important to figure out what’s the underlying customer problem that this idea is trying to solve.
  4. A great method to evaluate a product idea — as every product idea has an existing alternative out there, try and figure out what users think of current alternatives. Essentially, it’s important to quickly understand the market landscape BUT from a customer’s standpoint.
  5. a) Every new product is a derivative of something that has already existed. b) It’s very hard to find a brand new problem. Problems remain the same, just that their nature keeps evolving, which in turn, creates opportunities for new products to be built. Ultimately, most software is a replacement for some sort of an excel sheet.
  6. a) Two ways to build startup products from scratch: 1) COPY-BUILD-ITERATE-GET TO UNIQUE. Copy fast, launch, then discover & find new things to innovate on. 2) RESEARCH-LEARN-BE UNIQUE FROM DAY 0. Learn how to be different first, but without shipping. Make something 10x better. b) If you are good at building teams and executing, go for Option a. If you are good at user research and patiently innovating, go for Option b. Choose the option that aligns most with your strengths.
  7. User research tips for startup Day 0: a) Usually, about 12 interviews are enough to develop a pattern. b) 2 questions to ask users (i) what’s your #1 pain point in doing X and (ii) walk me through a real story of the last time you experienced this pain point.
  8. a) Tip to avoid product over-spec’ing/ scope creep: for any feature that needs to be built, first figure out the exact “Step 1” to be built for it, and keep a constraint of “it should be shippable with 1 week/ 40 hours of engineering. effort”. b) This Step 1 should be crude enough that it gets built quickly, but just sufficiently spec’d so that it can drive the user validation exercise. Eg., before building a full sharing capability, just put a dummy sharing button that on clicking, asks the user “what are you looking to do here?”.
  9. For effective product road-mapping, always ask the question “what part of this product is getting the most usage?”. That’s the area that will drive adoption and where you should be doubling down on.
  10. Build a highly customer-centric product team. Everything you are doing needs to be solving a problem for the customer. Keep that focus and discipline.

I have learned many of these points first-hand while building Workomo from scratch over the last year or so, so I can attest to how useful these product heuristics are. Would love to hear some of your own learnings as a founder/ early-stage PM, so we can keep adding on to this cheat sheet.

User research as the art of story-t̶e̶l̶l̶i̶n̶g̶ hearing

At Workomo, we operate on an extremely agile & iterative execution cadence. Since launching the first sign-up landing page in June’19-end, we have iterated quickly & decisively. Workomo’s first MVP was released in Aug’19 — a simple web app that was nothing but an “automated spreadsheet++”, something I built for myself. We immediately started moving towards a much more “contextual” product, releasing Workomo Chrome extension v1 in Oct’19 and v2 in Dec’19. Again, based on user feedback, we realized that Workomo needed to be mobile-first. We again did a fast cross-platform iteration, releasing the iOS app v1 in private beta last month and are now, on track to release a significantly upgraded v2 in Feb’20-end.

The key to executing at this pace has been intense customer development. Especially in this new year, user research has been a P0 for us, with specific monthly goals being set on what we want to achieve on this front.

Personally, for me, this has been a steep learning curve on how to speak to users. Based on the last several months of iterating on Workomo, I am sharing my top 10 field techniques that hopefully, will be helpful for your own user research process.

  1. Maximize in-person interviews — in Q4 of last year, we did many user interviews over the phone & zoom calls. Starting Jan’20, we have doubled-down only on in-person interviews in the Bay Area. And what a difference it makes! The ability to connect with users and read their body language — when they are pausing, thinking hard or feeling uncomfortable, these are invaluable signals for conducting effective user research. So, get over your inertia of stepping out of the building, log the required miles and go where users are.
  2. Choose a comfortable meeting ambiance — in my experience, relaxed coffee shops with spread-out seating arrangements & less background noise, make it easier to connect, listen and share. User research needs to happen with “intent”, so food, drinks & music are usually distractions that are best avoided.
  3. Voice-record with permission — taking physical notes during user research is incredibly distracting for both sides, and very often, important moments in the conversation that require an immediate “Why?” counter-question, fall through the cracks. I highly recommend taking explicit permission from the user, and then, doing a voice memo recording of the discussion. Having an audio file also makes it easier to evangelize within the larger product & engineering team, as well as for your own later reference for analysis.
  4. Understand user’s life through open-ended questions — let users drive the conversation flow, and in turn, immerse yourself in understanding aspects they are organically inclined to talk about. As founders, we have a tendency to execute user research as a “filling the gaps” exercise. However, this is often not a useful approach for in-person interviews (might work for surveys). Rather, I recommend the “hear their story” approach, driven by genuine interest & curiosity. How do they approach things? What do they care about? Why they do what they do? What do they find easy…and hard? Your job is to collect enough of these stories, synthesize them and then do an aggregated gap analysis. Think of it like connecting the dots; even better if each dot is unique and different from the other one.
  5. Don’t bias users — asking leading questions like “will you use this feature?” or “is this feature good?” will always lead to biased answers. Avoid putting things in the heads of users, so feature-centric questions are usually best avoided. Something I recently learned from my founding team is to always keep demo of the actual product towards the latter half of the meeting, once users have already answered your persona-based questions. This will ensure their answers in the first half remain unbiased.
  6. The 5 “Whys” technique — I had read a while back about how Toyota pioneered this technique to get to the root of any problem. I have found this technique to be immensely valuable for user research. A mistake I made many times earlier was trying to go “wide” by asking one new question after another. User interviews give better return-on-effort if you go “deep” by asking multiple Whys on each question and let that guide the overall research flow. Each interview then becomes valuable to understand one aspect of the problem deeply, and by putting many such deep interviews together, hopefully, the overall picture starts to unravel.
  7. Use tag-teams — I always felt handicapped in doing user research alone, as it’s impossible for one person to simultaneously listen, analyze, ask a “why”, process the flow and decide on a new question. I have found tag-teaming to be a better approach, where 2 people take turns to ask questions & engage with the user, while the other listens, absorbs and decides on what new set of questions are emerging. It also helps in making the process less monotonous.
  8. Mentally plot each user on the “adoption curve” — post each interview, as you debrief with your tag-team partner to analyze responses, do 2 things — a) map the user to either an existing or emerging “persona” in your head and b) place the user (& persona) on a specific part of the adoption curve. This will help you in TAM & GTM planning. As a corollary, try and speak to people at “extremes” of this adoption curve, so you start putting boundary conditions and your product’s specific adoption curve starts emerging.
Source: The Four Steps to the Epiphany by Steve Blank

9. Talk to “target” users, as opposed to “convenient” users — user research can be an incredibly grueling process end-to-end, from identifying users, getting intros or conducting cold outreach, to coordinating logistics, commute times etc. This creates a tendency to speak with users that require less effort, even though they may not be relevant for your product. Keep your research process honest & aligned with company goals, to avoid capturing signals that are just plain wrong.

10. Embrace the “I just don’t have this problem” response — consciously talk to users who aren’t normally your target audience and aren’t even using comparable or competing products. Sometimes, they will give you ideas that can help you increase your TAM.

Before I sign-off, I strongly recommend these 2 YC talks on user research — How to run a user interview by Emmett Shear (Founder & CEO of Justin.tv and Twitch); and How to talk to users by Eric Migicovsky (YC Partner). Eric, in particular, highlights the following first-principles way of framing questions that applies to almost all contexts:

— What is the hardest thing about…?

— Tell me the last time you faced this hard challenge?

— Why do you think it’s so hard?

— What, if anything, have you tried to do to solve the problem?

— What don’t you love about the solutions you have tried?

Would love to hear any user research best practices that have worked for you over the years.

About us: Workomo is a “System of Intelligence” for professional relationships, targeted at global power professionals or “prosumers”. Our iOS app is currently in private beta. If you would like to give it a spin & provide early adopter feedback, do leave a comment on this post and we will get in touch with you directly.

What can you learn from Superhuman’s product-market fit playbook?

[Update on Feb 26, 2020] Rahul Vohra has recently published a super cool interactive tool so people can use Superhuman’s PMF framework for themselves. Check it out here.

As I am building-out my startup Workomo (helping knowledge professionals supercharge their professional relationships), have already used so many ideas from this method. My detailed take in this article below.

One of the best articles I have read in recent times is How Superhuman Built an Engine to Find Product/Market Fit by Founder-CEO Rahul Vohra. As I have been building Workomo over last few months, the overarching goal for me as a founder continues to be — how to achieve PMF while minimizing time spent & capital utilized? Having read Marc Andreessen’s legendary essay on defining PMF (“Product/market fit means being in a good market with a product that can satisfy that market”), as well as all YC stuff on the topic, I had developed a playbook for it in my head:

  1. Make something people want
  2. Be lean (product development approach + capital)
  3. Launch simple & quick
  4. Organic demand generation (networks + communities + word-of-mouth)
  5. Identify early adopter persona
  6. Iterate based on their feedback
  7. Eventually “delight” & consequently, “retain” early adopters
  8. Test how much will they pay
  9. Get to 10, then 100, then 1000 “retained & paying” users
  10. Scale-up from there

As a founder dealing with so many unknowns, one is always looking for actionable insights, more than theoretical advice. Reading about the Superhuman experience just gave me so much execution color on this PMF playbook. I think every founder (and even venture investor!) should absorb these valuable insights so sharing my notes & key takeaways from this article.

Summary of Superhuman’s deconstructed product-market fit playbook:

#1 PMF takes time

#2 Quantify PMF via a single, North Star metric

#3 Structure & execute the user survey process well

#4 Create a highly detailed user persona of the High-Expectation Customer

#5 Focus on delighting a small number of users first

#6 To convert users that are “one-the-fence”, focus on what your fanatic users love the most about your product

#7 Two-pronged product planning approach to move towards PMF — focus on core strengths + address core concerns

#8 For feature prioritization, stack-rank to get to “lowest cost, highest impact” features

#9 Rinse, and repeat…

Let’s dive into these elements in detail.

  1. PMF takes time

Superhuman team first started coding in 2015 and it’s only in last few months that they have attained a critical mass of vocal adopters, who are in-turn, making the product viral. A reality check for all of us in terms of how much time it truly takes to make something people want, and therefore, the value of patience in founding teams (& investors).

2. Quantify PMF via a single, North Star metric

A big challenge in working towards PMF is that it appears “fluffy”, especially when as a founder, you are trying to align your engineering & product teams around it and even more so, when you are trying to set an actionable & trackable process roadmap for it.

The best way recommended is to quantify PMF in terms of a North Star “leading” metric.

The Superhuman team used the following leading metric to quantify PMF (originally articulated by Sean Ellis in this article) — just ask users “how would you feel if you could no longer use the product?” and measure the percent who answer “very disappointed”. The threshold for having achieved PMF is 40%.

3. Structure & execute the user survey process well

Perhaps the most refreshing info in this article are the details Rahul shares about the user survey process they ran, to gather data on the PMF North Star metric:

a) Identify users who used the product at least twice in the last two weeks

b) Exact survey that was sent out given below (just the minimum number of critical questions were included, amazingly succinct yet effective!)

PS: I loved the 2nd question, where existing users are prompted in a way, to describe their own persona. Makes it so much easier to clearly identify who your real early adopters are. More on this later.

c) Classified the responses into 3 buckets — 1) Very Disappointed, 2) Somewhat Disappointed, and 3) Not Disappointed.

d) Assigned a persona to each bucket, to identify the “Very Disappointed” user persona (the actual early adopter)

To me, this entire user survey process is the core of the PMF playbook, and something I found exceptionally insightful.

As has been my learning doing Workomo’s customer development process, at this really early stage of the company, the number of respondents matter much less than you think. Some data is better than no data, especially coming from actual, retained users. Superhuman mentions anything more than 40 responses as an adequate sample size (at the time, their universal sample set was only ~100–200 users that could be polled!!)

4. Create a highly detailed user persona of the High-Expectation Customer

I think the most clever trick in the above user survey structure is Q #2 — “what type of people do you think would benefit most from Superhuman?” ‘Cos, people tend to describe their own personas as a response. Analyze responses to this question only for the “Very Disappointed” bucket, and you end up with detailed personas that users themselves have pretty much self-created for you!

Going from this 1st level user persona…

1st Level User Persona

…to the 2nd level user persona.

2nd Level User Persona

PS: have been searching for what an optimally-sized user persona should be like for a really early stage startup. This is a great example — ~200 words, 2 paras; captures both professional & personal behavior, motivations, quantified behavioral characteristics, relevant life goals and desired outcomes/ end-state.

5. Focus on delighting a small number of users first

Paul Graham always says it; Superhuman case study just confirms it — define a narrow market, delight, dominate & then grow out from there.

Reproducing this quote by PG, just to drive home this point:

“When a startup launches, there have to be at least some users who really need what they’re making — not just people who could see themselves using it one day, but who want it urgently. Usually this initial group of users is small, for the simple reason that if there were something that large numbers of people urgently needed and that could be built with the amount of effort a startup usually puts into a version one, it would probably already exist. Which means you have to compromise on one dimension: you can either build something a large number of people want a small amount, or something a small number of people want a large amount. Choose the latter. Not all ideas of that type are good startup ideas, but nearly all good startup ideas are of that type.”

6. To convert users that are “one-the-fence”, focus on what your fanatic users love the most about your product

Key to converting more on-the-fence users into fanatic users is first identifying the core 1–2 strengths of your product. The reason being, non-fanatic users that fundamentally care about these strengths, are the ones most likely to convert into fanatics. However, this requires addressing their top 1–2 product concerns.

In Superhuman’s case:

Core strengths (as told by fanatic users)— speed, focus, keyboard shortcuts

% of “Somewhat Disappointed” bucket users, who care about “Speed” as the main benefit — 30%

For these 30% of “Somewhat Disappointed” users, what are their primary concerns (as told by them in the survey)— lack of mobile app (MAIN) + integrations, calendaring, better search etc.

7. Two-pronged product planning approach to move towards PMF — focus on core strengths + address core concerns

Boom! Post the above 6 steps, now you have a clear roadmap of features needed to convert on-the-fence users to fanatic users, and inch closer towards that elusive 40% PMF benchmark.

Your PMF product plan needs just the following 2 strategies — 1) doubling-down on core strengths that are loved by fanatic users+ 2) working to allay concerns & feature requests from on-the-fence users.

8. For feature prioritization, stack-rank to get to “lowest cost, highest impact” features

Use a combination of survey data and your qualitative product instinct to arrive at the low-hanging features (low cost + high impact) that can start delivering immediate value to users.

9. Rinse, and repeat…

…until you get to PMF!

Hope you find this deconstruction useful for your own journey towards PMF. Would love to hear any specific strategies that have worked for you.

Side Note: am currently building Workomo, a smart & simple professional relationships management hub for the new-age knowledge professional. If you would like to transform yourself from just a “networker”, to a deep “relationship builder”, do sign-up to receive private beta access. Also, check out this post on Workomo’s long-term Mission & product thesis.

How to think about building features at the beta stage?

It’s been an interesting journey for me as a product person, building Workomo over last few months. Having anchored the company mission on my personal pain point, the product roadmap for Workomo (at least for next 24 months) is quite clear in my head. Still, it’s not been easy to think through the order & prioritization of building features. This is a completely new “0-to-1” challenge for me as in my previous roles at Alibaba, Quixey and IDG Ventures, I was mostly used to evaluating, building & scaling products with at least some existing user traction.

As I work towards the private beta release of Workomo, the following frameworks have been really helpful for me in product planning:

  1. Running Lean by Ash Maurya — I really identify with the Lean way of building early stage products. While certain elements of the Lean process haven’t worked particularly well in my case (mockup based proto, hacking a solution without UI/ UX considerations), I have actively used the major core principles of Lean philosophy — iterative approach, user-pull over company-push, maniacally tracking return-on-effort, avoiding wastage, only focusing on 1–2 activities that matter at this stage of the startup. Though, it’s important to point out that I have found the need to adapt these approaches to my context by suitably modifying them.
  2. Focusing on the product’s “Atomic Unit” — I learned of this concept via a recent LinkedIn post by Pravin Jadhav. It was originally articulated by Fred Wilson in this 2012 post. What are the atomic units of popular products? Twitter — tweet, LinkedIn — resume, Instagram — picture, Gmail — email, Dropbox — file. It’s a lovely way to think about your product stack. For Workomo, the atomic unit is “a contact”. And that’s what I am building first for the private beta release.

I was on a Zoom call today morning — the moment I ended it, I received this version update pop-up, with following new features:

Zoom is releasing features like confirm starting video when joining a meeting, dropbox integration etc. ONLY AFTER going public!! Just proves that as early stage founders, we need to be much, much more disciplined about building additional features into our products.

Ultimately, there will be one, core UVP feature that will mainly drive user adoption. Our job as product founders is to discover & build it in an iterative manner while burning through minimum set of cycles.

PS: Workomo is your smart & simple professional relationships management hub. If you are sick of managing your networks on an excel sheet, do sign-up for free private beta access.