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:
Framework for evaluating whether the “problem to be solved” is worth solving — is it 1) frequent enough, 2) painful enough and 3) urgent enough?
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”.
“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.
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.
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.
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.
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.
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?”.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
