A few weeks back, I spoke to product management and entrepreneurship thought leader Sachin Rekhi for The Lean B2B Podcast. We talked about customer development, customer research, and various strategies to collect (and learn from) user feedback.
Etienne Garbugli: Great. So, my guest today is Sachin Rekhi, co-founder and CEO of Notejoy, a collaborative notes app for teams. Sachin is also a thought leader, writer and speaker on product management and entrepreneurship. Previously, Sachin was the founder of anywhere.fm and Feedera, both of which were sold to large organizations.
He’s also worked at LinkedIn where he incubated and launched LinkedIn Sales Navigator. He worked at Microsoft in the beginnings of his career. Nice to meet you, Sachin.
Sachin Rekhi: Great to be here. Yeah.
Etienne Garbugli: I have a few questions today for you. So, trying to figure out how you go about learning from the market, you go for about learning from different hypotheses, so you can make products move forward, and you can reach product-market fit initially but later on as well as keep learning from your users and your customers.
So maybe first question. If an entrepreneur work to start a new business tomorrow, I would you recommend they go about doing that like, what’s the starting point?
Sachin Rekhi: Great question, you know I have started, you know, multiple companies now and my approach has been kind of all over the place. You know, when I started anywhere.fm, my first startup the origin stories as crazy as it gets basically we came up with a startup idea. We pitched it to Paul Graham at Y combinator and Paul actually said, you know, I hate your idea, but I really like your team.
So, you guys are in YC only if you come up with a new startup idea. And so, we were required to very quickly kind of come up with a new idea. Did very little due diligence on the idea and then ended up kind of building out anywhere.fm. That was in stark contrast to the next startup I started which was Connected a contact management tool that ultimately went on to sell to LinkedIn.
But what was interesting about that one is I got the opportunity to be an Entrepreneur in Residence at Trinity Ventures. And so, I actually really kind of dedicated my entire time my EIR which is almost five months to really thinking through and vetting ideas in a very specific way before embarking on the idea in the first place.
And that has sort of become the mainstay of how I kind of think through these things. And so, what I always suggest is actually come up with what I call the eight product-market fit hypotheses for each startup idea. And so, the idea is that you basically create just a two pager for each of your startup ideas that covers each of the key elements or the hypotheses that you’re making for your startup.
So, this includes everything from things like who’s your target audience? What’s the problem you’re solving? How are you planning on acquiring new users? How are you planning on monetizing? How are you going to differentiate from the core target audience? And ultimately, what are your success criteria and KPIs look like.
And the reason why I like this approach is that it’s very easy when coming up with a startup idea to very quickly get excited about maybe the product and the product differentiation, but we all know a startup to be successful takes way more than just a really compelling product and by detailing each of these key hypotheses, you’re kind of looking holistically at the business and you might find for example that, while you know while you have a great product differentiation you haven’t yet come up with a great user acquisition strategy to acquire new customers to the startup. You know, if any of these dimensions doesn’t have a solid plan. It turns out you still don’t have a viable startup and it becomes a great holistic view of looking at all of the key dimensions.
The reason I recommend this over some of the traditional approaches like a business plan is, you know, a business plan ends up being something that could be 10-20-30 pages long, and unfortunately that length sort of gives you this false sense of precision that you kind of know what you’re doing and you have all these details so it must be right instead the short one to two pager with just a paragraph on each of your key hypotheses.
I find is the right fidelity to allow you to iterate on it. It feels easy to change a paragraph as opposed to change 10 pages and that’s what you want to be doing at the earliest stages of your startup iterating on each of these hypotheses as quickly as possible but looking. Holistically at the startup idea.
Etienne Garbugli: Okay. So now you have a plan you’re putting in place so you can start thinking about that iterating on these hypotheses a little bit. Once you’re satisfied with the basis of that like, how would you move forward in terms of figure out if there’s a market demand if it’s going to connect with the market.
Sachin Rekhi: Yeah, so I think the way I like to do this is initially when you’re coming up with your startup idea, you know you want to talk to as many people as possible to really start to vet out, you know, are you solving a real pain point this could be industry experts. This could be other entrepreneurs. This could be other venture capitalists. All of those are really helpful when you’re kind of thinking through, you know, ultimately is this going to be a sound business. The reality though is the number one person you can talk to is definitely your target customer.
They’re the ones we’re going to provide obviously the most interesting insights into whether you’re solving a real pain point and early on in the process. I think the key thing to understand is less about kind of the product design and the product details you’ll get to that later but early on it’s all about, are you solving a real pain point that’s actually fairly painful for the end-user right and ultimately the end customer and you know, I think it’s really important to really understand. Are you building a vitamin or a painkiller? And this sort of style of kind of customer research early on is all about pain point analysis.
And so, you’re really trying to get at when you’re talking to your customers understanding their day-to-day workflow of their tools and software or whatever they might be using and then trying to get at. You know, where is the pain in that workflow today? And then sort of bringing up this idea of hey, I’m thinking about building this product or business that might address this pain and then really trying to understand whether that concept resonates with them.
And again, you’re trying to still assess how painful is that pain because it turns out so many things are kind of inconvenient, but do they go to the point of being enough of a pain point that it will cause your customer to completely change their workflow cause them to buy your new product that is a certain level of pain that’s much higher than just an inconvenience.
Etienne Garbugli: So in that case, you’re talking about painkiller versus a vitamin, how do you figure out what are so the signals that you’re looking for to figure out that this is a painkiller or this is going to be a vitamin?
Sachin Rekhi: Great question. I’d say that it frankly isn’t an easy answer some of the things that we looked at when we were building B2B products.
So, for example, when we were building LinkedIn Sales Navigator at LinkedIn, we were building a brand-new sales product from scratch and you know, while LinkedIn had a general subscription for sales professionals, you know, they have really hadn’t built something kind of dedicated in a deep way to sales professionals.
So, what we wanted to make sure when we came up with what the key value proposition was going to be for this product that it resonated with potential sales professionals. And one of the best questions we had was as we came up with a product and got to the point where we had even kind of a high-level kind of mock-ups of what the product might do and what’s useful we started to ask our target customers: Hey if this product existed today, would you put it on your road map for next quarter to implement it? And we were talking to specifically the people that would be responsible for this. In our case, when you’re selling a sales tool, it’s often sales operations or sales leadership that end up being responsible for the rollout of any new sales tools to the organization. And so, we went to the sales ops team. We presented our concept and we asked them would this be on your road map for next quarter. And what’s interesting about it is you get all sorts of answers you get things like well, you know, this is really interesting.
But you know turns out we have all these other high priority things going on. So, like. You know, it turns out probably not next quarter maybe a couple quarters from now and you know while that might sound like an anecdote that’s very specific to a given customer when you hear that five times, it means you haven’t yet come up with a compelling value proposition because they keep delaying and delaying it and you have a vitamin not a painkiller.
And so that was one really helpful question that really got us to the point of believing we had or had not product-market fit specifically with the concept in a B2B case. And so, I think that’s one question you can use on the B2B side. I think the consumer side frankly is a little tougher, but definitely one question to think about.
Etienne Garbugli: Okay. So, in that case you guys had a pitch or an idea of what the solution was, you did not build a product but you were still approaching these potential customer potential organizations and you were trying to see what were their hesitations and the objections that they had in terms of going with the product.
Sachin Rekhi: That’s right. Actually, it’s completely right we had you know at that point what I described the product as is a PowerPoint deck. PowerPoint deck talking about hey, here’s the pain points that we perceive in your existing sales workflow. Here’s how we think LinkedIn can actually make that entire workflow better by taking advantage of all the unique insights and data that LinkedIn can bring to bear on its hundreds of millions of members and here’s the specific value props and features we’re thinking about building to solve for that and over time this initially started with just value prop statement. So, we’d go talk to customers and we literally have you know, a value prop that we wanted to kind of talk to them about in our case. It was you know, help find the right prospect that is likely to resonate with your product would be, you know, one value proposition or you might have another value proposition around help find the best path in to get a warm introduction to your potential prospect that you’re reaching out to and we kind of asked them which of these resonate which of these don’t resonate which ones do you feel like your current tool solved well enough and which ones don’t after we iterated on those concepts and came up with sort of a short list of value propositions.
That’s when we actually started putting designers to work to kind of come up with what might this look like as a user interface. We knew that. You know, the initial designs weren’t about kind of coming up with a final UI but really try to illustrate kind of the concepts and so we’d come up with these UI designs and then ultimately, we kind of made this kind of click through prototype of what this product might look like and that became the bulk of the deck.
And so, when we were doing these interviews, we were walking them through this deck and then seeing how well this resonated and at this point we had done zero engineering work against the actual. Like every little focused on customer discovery and really understanding do we have product-market fit on the concept that we’re planning a building.
Etienne Garbugli: I find it very interesting. You were mentioning in a different talk about how you really separate the problem from the value proposition and the solution. So, can you maybe talk a little bit why you keep the value proposition very separate in that case. And how would you go about selecting which one to move forward with?
Sachin Rekhi: Yeah, great question. I’d say that you know distinctly understanding the problem independent from the value proposition and the solution is super important. And the reason is because it’s easier for customers to help you understand their pain points and the problems with their existing workflow because they live and read that every single day.
And so, getting a clear succinct understanding of what that is. Is it is independently important than your solution I think too often when you’re doing customer discovery you jump to getting validation on the specific solution you’ve come up with without spending enough independent time understanding the pain point and the reason that’s really important is because it turns out you’re likely to keep iterating on your solution. Your solution is going to be changing either entirely through a pivot or through small pieces of it, and what gives you a sort of confidence being able to do that is the fact that you deeply understand the problem space. And so it’s really important to kind of separate the two and then you might find for example that your problem is resonating but your solution is not and then that allows you to go back to the drawing board to come up with potential other solutions or value propositions to address that pain point more importantly what you might find is that you get a lot of head nods to your solution, but the biggest challenge is that the problem that you come up with that that solution solves is a nice to have not a need to have. And now even if you go and build this product in this solution, you know a customer is desire to completely change their workflow and pay for a new product to solve a nice to have tends to be way lower than you expected.
Even if they upfront told you that the solution is more elegant than whatever they’re doing today.
Etienne Garbugli: Hmm interesting. So, in that case like within that phase, how do you make sure that you’re actually making progress that you actually like learning forward and getting closer to your objective of reaching product-market fit and beyond?
Sachin Rekhi: Yeah, so like one of the key techniques that we use for building LinkedIn Sales Navigator was actually doing what we call waves of customer discovery interview. Okay, and so what we would do is we might for example in a given week set up five different interviews with potential customers and normally, you know, in our case we’d have them come in for maybe an hour-long session.
And then we’d schedule like a 30-minute debrief after each session and you know, we then actually would set up maybe five of these either in one day or maybe you over a couple days in a given week. And what we would do is we had come up with that as I mentioned that kind of PowerPoint deck that we’re using as the basis of our customer discovery and we presented through them walk them through it get their feedback at their insights and after each 60-minute interview, the customer discovery team would do a 30-minute debrief and our customer discovery team would include product managers, designers, ux researchers, and even engineering leads and test leads and we bring them all together. We’d be watching these interviews live in real time. And then we had that dedicated 30 minutes of post-mortem.
That was really important because then we talked about what insights did each of us see from that conversation with the customer. What I love about this approach is that it’s in stark contrast to the way a lot of teams work. A lot of teams work is you have one ux researcher out doing the interview and then he kind of summarizes his findings and sends it to the team, you know while that might feel more efficient from kind of a cost perspective of number of people involved I find that loses a lot of great insights because what I find in every one of these debriefs is that it turns out people disagree on what they heard from the customer might they might actually say wait a minute. Why did you draw that conclusion? I saw it completely differently and then it forces people to get to what observation they made from that customer interview that led them to that conclusion.
And then it allows you to get to some sort of consensus on, Oh, what did we all really feel like we heard in terms of takeaways. So, then we do this for each of the interviews say the five interviews and at the end of the week, we’d come back and again in a session really debrief on what were the commonalities that we heard across these five folks.
And what do we think are things that are clearly things that are resonating as well as what are things that are not resonating. This would lead us to some kind of understanding of what changes we were going to make to those concepts those value props in that deck that we were going to present and then we’d make those changes and then we do the second wave of interviews the following week.
We did, you know five or six waves of interviews for Sales Navigator and you know, this this is kind of an expensive process you’re talking about bringing in, you know, 30 or so folks to go make this happen, but it was worth it because it allowed us to really deeply understand what the product offering needed to be well before wasting engineering resources, which is far more expensive. And I think that that was our process but to your point question on how do you know you’re moving the right direction? You know, what we realized is that you needed to come up with some kind of exit criteria for your concept to get a sense of and we’d ask this in every interview question.
The one I mentioned earlier is the one that we used initially which was, you know if this product existed today, you know how likely are you to adopt it in your quarterly roadmap? What we ultimately transition to as we got into later waves was hey, we would love if you’re excited about this concept to sign up for a pilot of this product.
And so, you know, we had formalized what the pilot program would look like. Initially the pilot program was completely free. So, there’s no cost but it turned out, we did require them to onboard their sales team on to the product at least a subset of them and to go through user feedback sessions where they’re giving us feedback on the product which is committing, you know, the time of a lot of their current team to use a new product to give us feedback.
And so, they really had some skin in the game if they actually chose to say that they’re signing up for. The program and we actually made those like a mini little contract that they had to sign basically say hey, are you signing up for doing this deployment, even though it was a free product and what we realized was again initially when we did the interviews we’ve got friction like well, you know, I really like the concept but again, I don’t know if I can commit my team to it but once we started to get to the point where we are hearing the majority of folks being like yeah sign me up.
That’s when we felt like, okay great. The concept is resonating even the designs are resonating. We feel like we’re really at that point where you know, we have a good sense of this is going to work.
Etienne Garbugli: Okay, so in a way you guys set a metric in place you did its guys decided and then you iterated based on the user feedback towards that objective that you guys were trying to reach or get customers to move towards.
Sachin Rekhi: That’s right. And I think what’s interesting about that is so many people when they think about A/B testing or quantitative analysis. They think about having a core goal metric which is also important, but I think what people are doing UX research and really trying to iterate a product to a point of do you have confidence that we’re ready to build it? you can again use a metric. It’s a more qualitative metrics for sure but it still is a guidepost of are we heading in the right direction? That you would use any sort of A/B testing metric.
Etienne Garbugli: Okay, so you kind of set a destination and at least at that point you can sort of decide or figure out if you’re going the right direction.
Sachin Rekhi: That’s right. Okay.
Etienne Garbugli: So in wonder you’re talking made a distinction between our product teams can learn from their users pre-product versus post-product. So how would you go about identifying gaps in the knowledge for your product strategy after launch once the product is in?
Sachin Rekhi: Yeah, great question.
So, it turns out that pre-product. Obviously, you can’t have people using the actual product. And so, you’re using these other user research techniques, whether its pain point analysis, card sorting exercises eventually get into usability test where your walking people through user experiences mock-ups and click through prototypes.
So that sort of the realm of user research and customer discovery that you can do before your product launches. Once your product launches you can still do those things, and you still should do those things but you’re opened up to a whole new realm of customer research that you can do and this is because now you can have people actually using the product and so the obvious one is definitely metric space analysis.
And this is understanding the usage of the product by actually looking at you know behavior. And so, this requires you to instrument the application in such a way that you can tell exactly what features people are using with what frequency using any of the off-the-shelf available analytics tools anything from Google analytics to an Optimizely whatnot.
And now you can kind of look at the aggregate behavior of all your users to understand which features of the using, which ones are they not using, how engaged are there, how often are they coming back, how retained are there for example, and so one of the things I always suggest teams do is to set up at least three dashboards from metrics to really understand kind of the health of their business.
And those are the user acquisition dashboard, engagement dashboard and the monetization dashboard. And so, the user acquisition dashboard is all about how you’re acquiring customers. How are they finding out about your site? And then how do they get through that kind of initial onboarding experience?
Then the engagement piece is all about what features are they using in the product, how often are they coming back, are they being retained? And finally, you know, ultimately, we’re in the business of making money. So, it’s important to understand how well your company is doing in terms of monetization and that will depend on the type of business.
If you have a freemium business, if you have a B2B business if you have an ad-streaming business. Those metrics will look different, but we all have some way that we’re making money. And so, it’s important to use those metrics-based analyses once you’ve launched. That being said, that’s not all you want to do.
I think what ends up happening is that I see some teams end up doing kind of classic UX research pre-launch. Post-launch relying significantly on the metrics, but the key thing to understand with metrics is that metrics are great at telling you what’s happening what the user is doing, but you’ll certainly never figure out why. And so, you still need to supplement your metrics analysis post-launch with customer feedback, direct voice of the customer that you’re getting to allow you to really understand why your customers are doing what they’re doing, what’s resonating, what’s not resonating, and what you need to do to improve it.
And so what’s important here is that in addition to leveraging the concepts of classic UX research like we’ve talked about you can again still do usability studies you do pain point analyses, but there’s a whole new set of techniques that are more qualitative in nature that come at your disposal once you’ve launched the product and you know, I’ve talked about this with the concepts of a feedback river and a feedback custom system of record that we can get into as well.
Etienne Garbugli: Well we can keep going that direction. That’s super interesting.
Sachin Rekhi: So yeah. Yeah, I was just going to say that, you know, one of the concepts that you know, I’ve come up with is sort of this idea of feedback river and let me kind of explain why this is important as I mentioned so often you end up in this case where.
Before product launch doing a lot of customer interviews, but post product launch you get so busy just iterating on the product in the features that it often becomes difficult to do these formulas kind of customer discovery sessions. And the reality is while they’re great in terms of like the feedback you get.
Most teams probably only do customer research maybe once a quarter at best frankly even less frequently because of how expensive it is to kind of conduct these studies you often only do it for major product redesigns or brand-new features, but not for continual improvement. And that’s because I’m kind of the expense of doing it on a regular basis, but you know as we talked about there’s a huge gap from simply looking at metrics.
And so, what I found as a kind of additional way to get user feedback is to come up with a continuous feedback loop a way that you’re constantly hearing feedback from your customers on a regular basis. And so, I think one of the best ways to do this is to develop what I call is a feedback river and the idea is that create one central place where all the feedback that you’re automatically already capturing from your customers is being funnelled into one place that anyone who’s interested in the team can access it. And so, what are the we actually built this as a Slack channel.
So, we have a feedback channel inside of Slack where all of the user feedback actually flows in for Notejoy.
And so, let’s talk about the different elements of feedback that flow into this. It’s anything from things like when a user cancels their accounts within Notejoy we ask them, Hey, can you please tell us why you’re canceling your account? And then that automatically goes into our feedback river so you can actually see when people are canceling their accounts.
We do the same thing when someone cancels their subscription. We also have an NPS survey that we run on every user 14 days after they’ve actually completed using the product and so after 14 days we ask them: Hey How likely are you to recommend this product to a friend or colleague on a scale of 0 to 10 and then we ask them: Why did you give us an answer? And so again this actually flows directly into our feedback channel and so because every user is hitting this on their 14th day of joining Notejoy, we’re constantly every day getting NPS survey results. And what’s great about it is when people love your product, they tell you why they love your product.
There’s something that they don’t like about your product. They tell you exactly what feature, what thing is bothering them. And so, this becomes continuous user feedback that we’re getting we also have done really interesting things where anytime anyone searches in our help center, that search query is sent to our feedback river.
Yeah so that end up being really helpful because it’s helpful for a couple things. First, it helps us improve our help center content. So, we run every search query that anyone else has executed against our help center and make sure that you get a good result. If we don’t, we add content we add keywords, we write more articles and we’ve been doing that quite a bit so we can help people self-serve but also what they’re searching for also gives you insights into what is likely confusing about your product.
We all attempt to build products that are super intuitive, but you know turns out it’s not always something that we can understand but when people are always searching for something, I remember initially with Notejoy people to always search for how do I add a notebook and we realized it wasn’t that intuitive to add a notebook.
So, we made it more intuitive to add a notebook. And so, we got a lot of insights from those search queries. We even do things like any time anyone mentions Notejoy on social media, Twitter and LinkedIn and Facebook those mentions flow into our feedback river. And so, what’s great about this is that now you’re continually getting feedback from your customers every single day.
And so, I dip into the feedback river in Slack just like I dip into Twitter. So, I’m standing the Starbucks line I have a few couple minutes free instead of going to my Twitter feed I go to my Slack channel feedback and listen to what customers are saying about my product right now and this sort of kind of allows anyone in your team require responsible for product development and product design to constantly have a pulse on the product.
What’s great about it is when you launch a new feature you tend to get more user feedback about what you currently launch. And this ends up being an incredible way to make sure you’re always getting voice of customer direct from the customer. You know, what I see when teams scale one of the challenges becomes they start to outsource a lot of their customer discovery work.
Maybe it’s a UX researcher doing research. Maybe it’s product marketing talking to customers and then the product development design team is kind of having a buffer between them and the actual customer research and primary research is incredibly important for anyone that’s in customer discovery and responsible for that because it turns out that you know, there’s lots Lost in Translation when there’s various people that are summarizing or synthesizing user feedback and it’s really important to get that directly and the feedback river is one of these ways to continuously get that feedback, but reduce the cost of it significant.
Etienne Garbugli: So you’re purposefully trying to stay very clear to the voice of customer to be able to learn about whatever is not going as well as you would like with the product and the business but as well.
Sachin Rekhi: That’s right and try to do it from a perspective of excuse me of understanding why because you know, the metrics analysis is going to tell you that hey people aren’t using this feature or people are being retained.
But the why is the hardest part and that’s where there’s no substitute to voice of customer to understand that.
Etienne Garbugli: Okay, maybe along that line. So, you made a really interesting distinction you’re writing about how. When you’re making changes, it’s either about increasing precision or about changing and hypothesis afterwards.
So, could you explain that a little bit more? And when do you know which avenue to take? When do you know which is which?
Sachin Rekhi: yeah, so like, you know, one of the interesting things is when we talk about kind of product-market fit hypotheses, you know those initial 8 hypotheses that every project or product or feature has, it turns out that you always start with a hypothesis that you came up with and I think when people think about kind of doing customer discovery and customer research, they simply think about this idea okay, I’m either validate the hypothesis or disproving the hypothesis. So, they’re thinking okay great the feedback I’ve gotten from my customers validates the hypothesis I had so let’s move on with the world. Or it doesn’t validate it. So, we need to change it. And so that’s the concept of simply kind of pivoting on a hypothesis.
So, you might decide for example that when you’re talking to a customer, it’s validated great or you might decide that no, it’s not resonating with the customer. So, no you need a pivot on it or change it. So that actually does happen. But what I think people forget is the more common thing that you should be doing is increasing the precision of your hypothesis.
And so, let me give a great example of this when we started Sales Navigator building Sales Navigator at LinkedIn. You know, we’re like, okay we want to go after sales professionals. That’s a very kind of broad statement and what we ultimately did through lots and lots of customer interviews is to increase that precision of who our target audience was.
And that was by understanding the core assets that LinkedIn brought to bear, understanding the kind of value propositions we were gonna solve for, and really by interviewing lots of different kinds of target customers starting to understand who these value propositions and solutions actually resonated with. And what we did is we went from this idea that LinkedIn is building a sales tool for sales professionals to LinkedIn is building a B2B sales tool specifically focused on B2B sales reps, not B2C sales reps.
We were also deciding that we were going to have sort of a focus on enterprise sales reps. We wanted to build something that was enterprise-scalable that works with the largest organizations and largest sales teams, but we also got into specific sectors. We knew that LinkedIn’s tools would obviously resonate with people in the tech industry, but we also found financial services as a strong secondary market to go after.
Okay, so now we’re getting pretty specific about the target audience we want to go after. B2B sales reps, you know in larger enterprises, with either a tech or financial services industries. And that is an example of increasing the precision of your hypotheses by virtue of doing customer research and it turns out actually most of your time spent in customer discovery should be increasing precision because our hypothesis in general was probably somewhere in the ballpark of right, but not detailed or granular enough and that’s why I think it’s super important to spend that time on increasing precision and think about your iteration not as just validating and pivoting but instead as adding meat and substance to the understanding of that hypothesis.
Etienne Garbugli: Maybe last question if you still have time. How would you prioritize those learnings in terms of improving the product? How would you go about figuring out what is coming out of the feedback river and everything else, and then figure out like, what’s the next thing?
Sachin Rekhi: Yeah, great question.
So that kind of jumps into the next concept I have which is developing a feedback system of record. Okay, and the idea here is that the feedback river is amazing for getting direct voice of customers that anyone can tap into, but it’s not enough to start making product development and product roadmap decisions.
And so, what you need independent of a feedback river is a feedback system of record. And this idea is that you have one place that you can go to look at the tallied-up customer feedback across all of the sources of user feedback. And so, the idea here is that this is sort of a CRM for customer feedback.
And so, you have basically this place where you can go, see all the feature requests that you’ve gotten and see how many people have actually requested that and, in some cases, or even putting specific names of those customers that requested it and. Way we’ve developed this at Notejoy is that we’ve actually made our feedback system of record public.
So we actually have a webpage called feature requests, and it’s a page that any of our users can go to actually vote up various features that they want to see added to the product and anyone can add new features anyone can vote up on existing features, but what’s important about it is not only is this end user facing but what we also do is we’ve made this actually something that we use internally, so when a customer sends us a support request and asks for a feature, we go and upvote on their behalf in that same tool that feature requests and that makes it so that we have one central repository for customer feedback. And I’ve seen what happens inside of organizations more classically is that they have even if they have a customer facing tool, the internal system that they have is completely different, and that’s unfortunate because now you have two different systems with two different tallies that really aren’t talking to each other. And so, we really built this in a way that it’s one system and often when we reply to the customer. We actually tell them: Hey, thanks for the feature request, I’ve upvoted this feature on your behalf on our feature request page. We link them to these request pages. And now next time they have feedback, they automatically go to the feature requests page themselves to go add feedback and participate in this discussion. And that allows you to have one central place where you have feature requests and tallied results what this allows you to do is that when you go into your roadmap planning, whether it’s your quarterly roadmap planning or Sprint planning, now your you often want to be using customer feedback and now you just can quickly pull up your system record and see hey, what’s the top requested features? What’s trending amongst? What’s now become very popular?
Given the themes that we want to take on for this upcoming quarter, what are the areas that customers have been asking for most? And what’s great about it with our system of record is it’s not only kind of a upvote list of features, but there’s a whole discussion forum on there.
And so. You actually get specific feedback that are like hey when you implement this, I hope you implement it this way or don’t forget to do this or don’t forget to add this feature to it. So that’s super helpful. But also when we start designing that feature now, we can go back to a set of users that are very committed to this feature maybe even send them mock-ups and we’ve done this in the past where we send them designs and said, hey guys, I know you’re super interested in this, here’s how we’re thinking about, what do you guys think about it? And we involve our customers into this process and involving the subsets that are really kind of interested. And so now the feedback system of records becomes kind of an important piece that you can use to actually prioritize your ideas to come up with that roadmap.
Okay, one specific caveat I do need to mention though. Is that when I first describe this to people like, okay great, I got my system a record. Now. Let me just implement the top request, right? That’s all I need to do. And actually, unfortunately the answer is no. Actually, simply implementing the most requested features is not a great product road mapping strategy.
It’s certainly an input to the process but it’s not the end-all be-all and there’s a few reasons for this. It turns out, you know, there’s a lot of things that you’re optimizing for in a business, you know, when we talked about these kind of three pillars of user metrics, user acquisition, engagement and monetization.
What you find is that when you’re getting feedback from customers and you actually implement those improvements that’s likely to improve the engagement bucket. It’s likely to get your existing users to use your product more regularly and to get them to retain more heavily. That’s great. But it turns out as a business owner you have to care about these other two dimensions as well. How you acquire users and how do you monetize them.
Rarely are you going to get feedback from a customer being like you should charge me more or you should put some feature behind a pay wall. So, you’re rarely going to get monetization feedback, but you still need to action that into your roadmap and you’re rarely going to get user acquisition feedback because it turns out the customers you’re not talking to are the ones that you aspire to get through user acquisition.
And so, there’s things that you have to juggle in the business that are independent of user feedback. And so, it’s important to take that holistic view as you’re coming up with your room. Equally important it turns out you might have ideas where to take the product that your customers aren’t even thinking of and so customer discovery is no replacement for getting rid of having a vision for your product.
And so, it’s still very important for you to have a vision and to independently come up with big innovative ideas that your customers might not be coming up with and then to prioritize that according on the road. And so those are just some of the reasons why you can’t just take you know, the list of customer requests and implement them, but it’s an incredibly important source of information that you certainly want to take very seriously when you’re doing your roadmap planning.
Without such a system of record, unfortunately what I see is a lot of recency bias where people are working on the roadmap, they decide: Oh, we should implement these customer requests and it’s literally the customer request they heard last week from kind of the loudest kind of most angry customers, as opposed to taking a holistic view on what really is the challenges across your entire user base and that’s what the system of record solves for.
Etienne Garbugli: So you’re because of that and because you’re looking at the trends you’re able to determine like what are the patterns that are coming up, and what’s currently the bird’s eye view of what’s really happening.
Sachin Rekhi: That’s right. And you’re able to have that bird’s eye view and then to put that in the context of what your business goals are that to decide what the right kind of roadmap elements need to be.
Etienne Garbugli: that’s super interesting.
Thanks for taking the time to chat today. That’s really appreciated. I think the listeners will get a lot of value from that. Where can people go to learn more about your work and to give Notejoy a try?
Sachin Rekhi: Yeah, so like if you’re interested in more of my thoughts on product management, I write a blog at sachinrekhi.com.
I’ve written over a hundred blog posts, videos, podcasts kind of talking about product management, product research, entrepreneurship. So definitely check that out and would also love for you to check out our product Notejoy, which is a collaborative notes app that makes it super easy for you to capture notes and then share those notes with anyone on your team.
So, just head over to know Notejoy.com to give it a try.
Etienne Garbugli: Awesome, so, we’ll share the links and really appreciate it. Thank you very much.
Sachin Rekhi: Thank you. Thank you.
More on Actionable User Feedback
- How to Generate Valid Customer Insights From Customer Interviews (Complete Guide)
- How Loopio Grew from 0 to 300 Customers by Focusing on Relationships
- How to Run Customer Exit Surveys to Improve Product Retention [The Definitive Guide]
Enjoyed this Episode?
Subscribe to The Lean B2B Podcast for more: