Sachin Rekhi

Ravi: Hello and welcome to the 89th episode of Yours Productly, a podcast series where we talk to product leaders from all over the world and learn from them how they build and manage world-class software products. Today, I have with me Sachin Rekhi again, with whom I had a podcast episode before, which was quite popular when we launched that episode. I’m very, very, very excited to have him back again and here’s why.

Sachin has a reputation to be a serious practitioner of product management. He has built several products in the past, led products at LinkedIn. His very popular blog, sachinrekhi.com provides a wealth of knowledge on building products. His stocks are also popular. You can find them on YouTube. What happens when someone with such a reputation launches his own product again, this time, something called Notejoy? So what happens is it draws a lot of attention towards him and drew my attention as well.

So I jumped on the chance to learn from his journey of building something from scratch that has already received such admiration and eruption for what he has built. Keep your eyes up and attentive because we are going to go really deep in this conversation. We have a ton of questions at my end and hopefully, we’ll get a chance to go through all of them.

Hello, Sachin. Welcome to Yours Productly Podcast yet again. How are you doing today?

Sachin: Good, good. Thanks for having me again, Ravi.

Ravi: The pleasure is always mine. First of all, congratulations for coming up with your newest product, Notejoy. Since all the questions will be based on your experience of building Notejoy, let me begin by asking you to describe what Notejoy is.

Sachin: Sure, happy to. Notejoy enables collaborative notes for your entire team. The whole idea is that it helps you get your team’s most important ideas out of email, out of slack and into a space that’s fast to capture, fast to get feedback and insanely fast to search. We’re helping teams better organize the 90% of institutional knowledge that today never makes it to a document or makes it to a Wiki. That’s certainly the quick description of what Notejoy is and what it’s all about.

Ravi: Thank you. My first question here is, so it is known widely through ample research and evidence that the number one reason for a startup to fail is because it is trying to solve a problem that does not exist. I personally found this tendency being so rampant amongst startup founders that I interact with. So this tendency comes from a bias towards your own idea. My question to you is when you decided to bring Notejoy, did you see a problem worthy of solving or was it a product of your own idea? If you can share some thoughts around that.

Sachin: Yeah, that’s a great question. I’d say that I started Notejoy with my co-founder, Ada Chen. What we really saw was that we had spent over the last decade working in technology companies, both small and large. Large companies like Microsoft, LinkedIn, SurveyMonkey, as well as small startups like our own previous startups like Connected and Anywhere.FM. What we realized was that despite all the collaboration tools that keep iterating and people keep innovating on, we felt real pain in collaborating on day-to-day basis in the organizations we were in.

This pain really started to be pronounced when both Ada and I became leaders within LinkedIn and SurveyMonkey, respectively. In those roles, we spent a lot of time thinking about, How do we make our teams efficient? How do we make our teams collaborate and stay aligned as effectively as possible?” In attempting to do this, what we just realized was that we’d spend all this time trying to drive alignment within our teams to make sure everyone was making the right decisions based on the strategy of the company, but that required so much over-communication. It meant that we spend so much time in meetings. It meant that we spend so much time sending emails.

While these things did help to solve the problem of making sure everyone was aligned and on the same page, it came at a huge productivity sync to the team. Spending time in meetings and writing emails is not the work that you want to be spending your time on, but it’s one of these necessary evils.

So what we felt was that even despite all of these attempts to over-communicate, to drive alignment and getting everyone on the same page, it still turned out when I went to various people on my team at LinkedIn and asked them, “Do you have all the information you need to be successful in your role?” More often than not, people said, “No.” They said that, “I’m sure there’s something going on in this organization that could be helpful to me that I just don’t know about.” I’m also inundated by things like slack feeds and email mailing list that I’m on, that it’s hard for me to get much signal in the noise.

From that, we really believed that this challenge of team collaboration still very much exist despite the fact that we’re using tools like email and Slack or Google Docs and Wikis or product management tools, all designed to help us work more effectively, but this overall pain point of team collaboration was still very real.

I’d say that’s where the genesis of the idea came from. What we felt was that Ada and I were both spending so much of our time using human processes, these meetings, these all-hands that I would run and really felt that the software was failing us, that it wasn’t actually helping us to be more effective to collaborate.

When we look at a lot of the tools that we use today, especially on the document collaboration side, things like Google Docs and Microsoft Office, they were really built in an era where most of the challenge was actually, thinking of them as authoring tools, where you author the document and print it out, maybe or emailed it to someone. We’re in a day and age now where we’re moving so fast that most of the work is iterating and socializing your ideas as supposed to just writing them down in the first place.

Ravi: Go ahead, please.

Sachin: Yeah, so like I said, that’s where the idea came from. We felt the problem space was very real, something that we had both experienced. As we both worked with product and marketing leaders at other companies, they said they experience the pain as well. Obviously, that means that the pain was very real. What the solution was, certainly, that we had a lot of validating to do, which I’m sure we’ll get into.

Ravi: Got it. Got it. You were diligent in validating your problem space. You spoke to different people and then you realized, yes, this is not something you, yourself, are imagining, but you saw that happening all around you.

Sachin: Yeah, definitely, on a daily basis.

Ravi: Got it. A really good question to this is, so you said you validated, but how do you see other founders? What is the mix where a founder is sure of a problem space and sometimes it is a leap of faith? Sometimes leap of faiths have what? Do you want to share a few lines around that on how much you should be sure of the problem you’re trying to solve instead of believing or taking a leap of faith?

Sachin: Yeah, I think it’s a combination of both. I think the best ideas do generate from pain points that you, yourself, have experienced because then you have a depth of understanding of the domain, a depth of understanding of the alternatives and competitors in the space. When you can be generative of your startup idea from the wealth of experiences you had in your own life, I think that’s incredibly powerful, both in terms of giving you a leg up of already being somewhat of an expert in that domain, but also, it usually means that you’re very passionate about that problem and not just doing it because you think that you could market opportunity.

Ravi: Got it.

Sachin: So I think that’s important. That being said, you always need to validate. You always need to make sure that this isn’t just a problem that you have, but a problem that others have as well. While people are maybe skeptical of the solution and maybe skeptical whether your idea will work, they certainly shouldn’t be skeptical that the problem you’re trying to solve for is one that they experience themselves.

Ravi: Got it. Thank you. Next question is from a quote that comes from Ash Maurya one of my favorite quotes here and it says, “Your product is not your product. Your business model is your product.” So when you came up with this idea that you wanted to solve, did you begin by writing a business plan or a business canvass or a lean canvass to gauge if the idea is valuable, feasible and usable?

Sachin: Yeah, great question. I’d say that my approach to this is something that I call documenting your eight product/market fit hypotheses. I’ve written a blog post about this, but the idea is that the traditional business plan, I think, is dead and that’s why you’re seeing a lot of these new models like a business canvas and a lean canvas. I think that’s the right direction.

I think it’s still incredibly important to start with a set of hypotheses that capture all the strategic components of your entire business. We did exactly this for Notejoy. We sat down and put this together. At the time, it’s just a one-pager. One single document that captures these eight product/market fit hypotheses. What I think is important about it is it makes sure you’re not just thinking about product/market fit. It helps you think about product/channel fit. It helps you think about product/model fit in terms of modernization strategy.

By having initial thesis on all of these dimensions, I think it then becomes something that you can decide what are the areas that are the biggest risks, that you’re going to spend time validating first either through prototyping or through testing whether people are willing to pay, whatever it might be in terms of your biggest risk and going from there. If you want, I can describe each of these eight product/market fit hypotheses one liner.

Ravi: Please do. Please do.

Sachin: Yeah, definitely. Let me go through what the eight are and what they were for Notejoy.

Ravi: What you are saying is you actually follow these eight principles, eight hypotheses that you blogged about?

Sachin: Exactly. Before we wrote a line of code, we had this document that was basically trying to delineate each of these. In fact, when we were doing a lot of our customer development interviews that we’ll get into, a lot of it was validating these hypotheses.

Ravi: Excellent. Please go ahead.

Sachin: Okay. So to go through it, first one, you always start with who’s your target audience. We believe with Notejoy that it ultimately could be a broad solution that was as broad as something like Google Docs and Microsoft Office. We knew we certainly couldn’t start with that as the audience. So what we decided was that we wanted to go after a more specific audience and we decided company size was going to be important eventually to us. SMBs and startups were something we thought would be low-hanging fruit in terms of helping us to try out new tools like Notejoy.

We also decided to start with R&D teams and marketing teams as the core segment we were going after. Part of it was because when Ada and I thought about the pain points we felt, it was through our experiences being leaders in product teams and for Ada being a leader in a marketing team. We thought there is a rich opportunity to create solutions there. So we built the solution with this target audience in mind, though, we generally expect it to expand it.

Ravi: Got it.

Sachin: Next was the problem you’re solving. Like I eluded to, we felt that teams were wasting significant time over-communicating. Yet, despite that, teams were rarely on the same page. Teams often couldn’t find the information that they needed to get their work down. So those ended up being the core problems that we tried to solve for in the solution that we were trying to build with Notejoy.

The third one was what’s your value proposition in terms of what kind of compelling value you’re creating for customers. For us, it was literally trying to address those problems we mentioned earlier directly. Helping teams to get on the same page faster, regardless of what product that we’re working on, but then also helping teams find the information they need in the role that they’re working in. So we felt that those were the key value propositions we were going after.

Then strategic differentiation was the next product/market fit hypotheses. For strategic differentiation, what we cared a lot about was user experience. We knew there was a lot of tools out there in the marketplace to help you do what you’re doing, but we believe that friction, all kinds of friction, whether it’s interaction friction, cognitive friction or emotional friction existed that prevented you from being successful in using these tools to get everyone on the same page and ultimately then to help you find the information you need.

So we spent a lot of time thinking about how from a user experience perspective we can solve all of these friction points. We’ll get into that in a bit.

Ravi: Tell me one thing. So these are hypotheses, right? I mean, so you are actually … Are these validated or now you are only writing your hypotheses at this stage?

Sachin: At the earliest stage, the idea was that we wanted to write these down.

Ravi: Got it.

Sachin: Many of them were very lightweight. Some of the things I’m describing are really just lightweight sentences at the beginning.

Ravi: Got it.

Sachin: Over time as we validate it, we were iterating on it. That iteration could either look like changing a hypothesis because we decided it was wrong, but more often than not, it looked like adding position and detail to a hypothesis that used to be a one-liner, turning it into a much more depth.

Ravi: Got it. Sorry I interrupted you in between. You completed four of them.

Sachin: Yeah. We talked about strategic differentiation. Then the next one is competition. When you’re thinking about competition, it’s all about what are the tools that people are using today, which are the direct alternatives, but also the indirect alternatives, that they weren’t using your tools what we’re using instead.

In our case, most people would look at a tool like Notejoy and consider the primary alternative tools like Google Docs and Microsoft Office. So those are the big behemoths that are the industry leaders. Obviously, there’s a bunch of startups in this space as well namely Quip and Dropbox Paper are probably the biggest ones, but plenty of other startups.

What we were more interested was the indirect competitors that actually we felt that if we’re successful, we’re not necessarily simply getting you to move your Google Docs and your Microsoft Office documents to Notejoy, but more importantly, we were hoping to get you to move your emails and your Slacks into a structured document collaboration tool like a Notejoy. So those indirect competitors were equally important as the direct competitors.

Ravi: Got it.

Sachin: Next is, obviously, acquisition strategy. So you spend a lot of time thinking about not how you build a product, but how do you actually create something that people will become aware of. We believe that with Notejoy, the strategy was going to be building a freemium product, so that we can have a free user base and then using viral growth based on the fact that Notejoy itself is sharing base products. This is very analogous to something like a Dropbox, where a lot of the fact that the way people discovered it was people simply shared files with them via Dropbox.

We thought we could build a lot of mechanisms within Notejoy to make it frictionless to share a content with your other colleagues within your organization and then ultimately, with colleagues outside of your organization and thought through a lot of the viral optimizations we could do to make that flow work. We felt that that would be our primary acquisition channel. Of course, we had layered on other ways to build initial seed audience and what not.

Ravi: Got it.

Sachin: Then we modernization strategy, thinking about how we’re going to make money off of this. We felt like there’s a lot of analogies to collaboration tools currently and that most of them have freemium product offerings, where they offered some bit for free, but then after that, they had a monthly subscription on a per user per month basis, usually, and let’s say $5 to $10, where you look at things like Google Docs and Slack. So we felt that was the tried and true modernization strategy that we were going to use and we’re going to move forward that.

The final one is KPIs. I think it’s really important upfront to define what are the KPIs you’re looking at in a weekly basis. That’s because you want to make sure that you’re spending time focusing on the right metrics. I think it also helps with the highs and lows of being in a startup. It’s too easy to look at an anecdote of one customer’s feedback and get depressed or excited about it. Instead, when you’re looking at specific KPIs, it’s way easier to stay balanced and rational in your approach.

So for Notejoy, we felt that if you’re using Notejoy on a regular basis, you should really be using it on a weekly cadence, especially from the perspective of we expect you to be thinking of Notejoy as a professional productivity tool for your teams. Early on, our key metric was weekly active users and also just our WAU/MAU ratio and thinking through how that was tracking over time. It also became a great early proxy for product/market fit as well.

Ravi: Got it. What I’m curious to know about this is some of this is matching with the lean canvas model like segments, problem space, value propositions. Strategic differentiation, I think it’s called unfair advantage. What I’m curious to know is why would you track KPIs right at the outset because KPI is something that is once the product is launched, you would be keeping a track off, right? Why should you be putting that as your first point to focus upon?

Sachin: I think for me, one of the biggest challenges I’ve seen with startups is that oftentimes, they’re very quick to get a product out and launch it broadly. I think what the nuance here is that you should get your product in front of potential customers as quickly as possible, but that’s very different than a public launch. So I actually think that we have this culture right now, where you very quickly move into a scaling acquisition phase when you in fact don’t yet have product/market fit.

I think that’s disastrous for startups because you end up spending a lot of time pushing new traffic and new users on your product. In fact, what you have is a leaky bucket and that users are coming in, but they’re falling off and not being retained.

So the reason we thought KPIs are really important and specifically, we wanted KPIs that were more measures of product/market fit as supposed to measures of a user acquisition and growth is because we were using this as a yardstick to help us decide are we ready for that big launch. We’re certainly going to have users coming in on a daily basis trying out the product, but does it really make sense for us to launch more broadly? I think having some yardstick set upfront and we had other ones, which we’ll talk about in a bit on product/market fit, I think that’s super important.

Ravi: I will be back with the interview in just a minute. In case you’re wondering, you are listening to Yours Productly Podcast. If you like the content on this podcast, I mean, if you really, really like it, do consider buying me a cup of coffee through the PayPal donate button on the website, yoursproductly.com. Donations help me keep my podcast ad-free and covers the cost of managing the podcast like website hosting charges, SoundCloud hosting charges and a lot of other accessories. Any help in this regard is much appreciated. Now, back to our conversation with our amazing guest today.

Got it. Okay. So you came up with this one-pager, where you wrote hypotheses statements for all these eight elements. What did you do next?

Sachin: So then the thought was that now that we have these, what we wanted to do is do a self-assessment of where we believed out of these eight product/market fit hypotheses the biggest risk was. Is it the problem statement? Is it the target audience? Is it the value proposition? What are the areas that we believe were the riskiest to give us a prioritized list of where we were going to spend our time?

Ravi: Got it.

Sachin: To give you a sense of that, modernization strategy, frankly, we thought was pretty straightforward. Pretty much all the document collaboration and broad collaboration tools had a very similar modernization strategy, either a freemium-based approach and then a multi-subscription or a straight monthly subscription in this price point. We actually felt like that one was low risk.

Ravi: Got it.

Sachin: That being said, we believed the biggest, biggest challenge was going to be strategic differentiation and value proposition.

Ravi: Got it.

Sachin: It turns out in this space, many people believe that Google Docs is good enough. It’s a pretty rich tool with a lot of great features. So we knew we had to create something incredibly compelling. We weren’t sure what that was going to be at the time and exactly how we were going to do it. So we knew that’s where we wanted to spend our time. That’s how we thought about beginning our customer validation process, knowing what were the biggest risks and moving on from there.

Ravi: So you found out that was your biggest risk and what did you do then for that to mitigate that risk?

Sachin: Then we started our customer discovery interviews. We have had hundreds of these so far in the journey of Notejoy. So what we ended up doing was having quite a few different product cycles for Notejoy. There was an alpha release, a beta release, a gamma release and then ultimately, our v1 release, which we launched back in December.

So along each of these, there was a set of customer discovery interviews that we were doing from the get-go. From the very beginning when we started our customer development interviews, our focus was really on trying to validate the highest level of these product/market fit hypotheses. When we talk to people, we’d layout literally our one-pager, have them review it and get a sense for, “What do you guys agree with and what do you guys don’t agree with?”

So what we were looking for was an understanding of, “Do you agree that the biggest areas of risk is what we’ve already identified or do you think it’s somewhere else?” What we quickly found was that people agree that the problem statement was very real. They could 100% resonate and relate to the challenges we’re working on with the team. They started to imagine, “How could you do it better than the existing tools like email Slack and Google Docs that already existed?”

So we knew that the biggest pain point, the biggest risk was, in fact, exactly what we had identified. We knew we are headed in the right direction of what we had to solve for.

Ravi: How were you picking these people and you said many, many interviews, right? Were they randomly picked? Were they in your friends circle or near and dear ones or how was it?

Sachin: Yeah. What we started to do was take a look at our target audience. As we described it as SMB, startups, R&D team and marketing teams, it turned out, obviously, we knew tons of those people. That’s exactly who our network was. We started reaching out to folks. We tried to be careful to find people both at large organizations as well as mid-sized startups, as well as real, true SMBs and micro startups just getting started.

We had a broad base company size, but then we also wanted to have a broad base of industry function. So not only do we talk to people in product and marketing, but business development and sales and a lot of the general departments that you find in an organization to help us validate do those parts of the organization and do companies of all sizes have this problem.

That was very instructive because when we went to our friends and colleagues in our network across all of these, what we realized was that a lot of the challenges were very different depending on company size. At the earliest stage of company, you’re not so worried about capturing institutional knowledge. You’re just really worried about getting things done and moving things forward and to staying alive.

So the problem to solve for there was slightly different than large organizations. Some of the biggest pain points in large organizations really didn’t apply to small startups. So I thought that was super instructive for us to hear that feedback by different company sizes.

Ravi: That’s how you focused. So you did not want to solve problems of both these different segments. So did you narrow it down to say, “Let’s solve it only for startups,” or something like that?

Sachin: Yeah, definitely. I think what we realized was that there was so much more functionality we’d want to build to address the needs of large enterprises. We thought that that would require us to not only build a great tool for SMBs and startups and mid-sized companies, but then also to build a set of functionality for large enterprises. So then we completely shifted our focus to SMBs and startups from the beginning because we felt like that was a more tractable problem to go after as supposed to the full solution.

Ravi: Got it. I am still at the problem space and I just want to go a little deeper here. I know I have taken a lot of time here, but this is very important. What made you take the plunge, Sachin? This is very important for me to understand. I know you identified the problem space. What made you go out all in and then invest your say, I do not know how many years you’ve already invested, I’m sure a couple of years, but what made you convince that, “This is it. This is where I’m going to spend my next two years and all my resources and build”? What was that one thing? Was it gut? I understand that you validated your problem space, but you need something more than that, right? That drive.

Sachin: Totally. Totally.

Ravi: What was that? What is that one thing?

Sachin: I think for me, it was mostly passion, actually. I think it’s one of these things where I’ve always been super passionate about building productivity tools. Back when I was young, I built a note-taking application called SachNotes. Also a great to-do list app called MonkeySort. I’ve always been really passionate about productivity tools. Even my last startup, Connected, which was a relationship management tool was really all about personal productivity when it came to managing your relationships and managing your contacts. That’s always been a passion area for me.

What was unique was that while working at LinkedIn and being a leader there, I saw all these challenges of team collaboration. What I realized was that you could bring a productivity tool bent and a productivity tool discipline to improving team collaboration significantly. I think Slack is an early example of this exact thing, where they’ve built a powerful tool with a productivity mindset of how do you geek out all the efficiency you can from users who are using this tool.

What I was passionate about was seeing if I could bring my productivity bent into a team collaboration solution. I think that was really the impetus to get me super excited to be like, “It’s time to move on from LinkedIn and really go after this space in the big berry.”

Ravi: That’s a big lesson. It seems like there is a consistence streak that drew you from your passion and that common thread was about creating something on improving productivity. I think that is also very important because I’ve seen entrepreneurs who just want to get started with something and they latch on to the first idea they have in their mind, but the lesson that I learned from you is it is much deeper than that, isn’t it?

Sachin: Yeah, definitely. You know what’s fascinating about it is that it’s not just passion. It has to be passion plus market opportunity. For example, my passion is productivity tools, but one of the reasons I’ve largely avoided building personal productivity tools or tools that are only used for personal productivity is they’re just very difficult to monetize and build a business out of.

For me, what was compelling about Notejoy was that we found a way to take this excitement around productivity, but apply to team collaboration where the market opportunity size is much, much bigger with Google Docs and Office being a $30 billion market in and of themselves. So finding that passion, but then also finding a great market opportunity is the hard part. You got to have both.

Ravi: Got it. All right. Moving on from the problem space, the next milestone, the first milestone is finding a problem worthy to be solved and you did that great. So the next milestone is the product/solution fit. How do you conceptualize a solution that will solve the problem that you have identified? Help me go through what was your … How did you come up with your solution and how did you validate your initial product? Did you do throw a lot of brainstorming, marking designs? How did you come up with your actual working prototype for the first time?

Sachin: I’d say there was a variety of efforts that we were doing. Independently doing a bunch of brainstorming to really think through what were the challenges and team collaboration that we can solve for and then constantly iterating with customer discovery interviews on those concepts. On the brainstorming side, we spent a lot of time going through what we felt was some of the biggest challenges that people face and we use this hierarchy of user friction model that I’ve blogged about.

This idea that when you look at the various frictions that exist in any domain, you have interaction friction, which really describes the challenges, use it in a product, really run the usability of it, you have the cognitive friction, which gets the cognitive load that you’re creating in people’s mind when they’re trying to use your product.

Finally, we have emotional friction, which is the way a product makes someone feel that either causes them to not move forward with a certain action or to move forward with it. What we spend time was brainstorming all of these kinds of friction that existed within team collaboration with the organization and really started to think about what were some of the biggest challenges.

For example, one that we identified on the emotional friction side is that it turns out that in organizations, you have a day job, which is driving results for whatever role you’re in. What we always hear is that we should do a better job documenting our findings. We should do a better job sharing best practices within the organization. Because that’s always a nice to have, not a need to have, it always falls by the wayside.

It turns out you’re going to get rewarded in your organization for things like doing a good job against your OKRs and things like that, but rarely are you rewarded for sharing best practices. So what we knew if we wanted to encourage people to be better at sharing best practices, we actually did have to attempt to solve this intensive problem to create some reward.

We thought there was a variety of ways that we can do that, both in terms of helping you get lightweight feedback on your work. So within Notejoy, we give you feedback in terms of when someone’s viewing your note. We’ll give you feedback in terms of lightweight reactions like thumbs ups and high fives just like you can in Slack. Then we also support full-threaded conversations all with the Notejoy, so people can provide lightweight feedback to even just tell you that they viewed your note, to full-threaded conversations in terms of feedback.

We thought that was a really important way to start to solve for some of the incentive problems. We also in Notejoy, when you’re adding content to Notejoy, it creates a profile, which becomes your internal author profile, which starts to become something you’re proud of, something that helps to show off a lot of your work.

So we felt this dimension of your emotional friction that exists that prevented you from taking all this time to capture and share institutional best practices was an insight that we felt we wanted to solve for that a lot of the tools that we thought were in this space were largely simply focused on cognitive friction or interaction friction.

Through that brainstorming process, we came up with some of the things that we thought we could do to actually potentially solve for it. That’s when we started putting it through customer discovery.

Ravi: How did that initial brainstorming process look like? First of all, how many people were involved? You and your other co-founder and were they the only ones or you had already built up a team more than that?

Sachin: No. Actually, it’s just the two of us. Still today, Notejoy is just Ada and I.

Ravi: Wow!

Sachin: Yeah, so just the two of us. I’m a big believer in minimum viable team just like minimum viable product. Obviously, Ada and I have taken it to an extreme, where it’s really just the two of us building up the product.

Ravi: That’s amazing. My question is how did that brainstorming session look like? What I’m saying is how did the first prototype or say, the first sketch look like? I mean, how did you know what is the first used case that you are going to solve and then add on top of that later? Was there a prioritized list of what you want to design first? I’m just trying to go a little scratch below the surface here.

Sachin: Yeah. So I’d say that once we spent some time identifying the friction points and a lot of what we were finding was that it turned out that people were documenting things in the course of getting work done, but oftentimes, it wasn’t, in fact, shared. A classic example of this was I’m in a meeting in LinkedIn and there’s 10 people in the room. As I walked around the room, I’d noticed that five people are taking notes in Evernote. Then at the end of the meeting, zero people send out meeting notes.

I’m like, “What happened?” It turns out there’s just a lot of friction points. This was just an example of what we notice was happening, which was that people would capture content, but then wouldn’t end up sharing it and that capturing of content would happen in a personal note-taking tool. It might happen in email and Slack, but it wasn’t happening in something that was captured and structured.

Ravi: That is so true.

Sachin: It created an initial hypothesis for us on part of the challenge was around capturing content and how do we simplify that process of capturing content. That’s where we began with our prototyping. We had talked to a lot of folks about that. From that, we had actually gotten their feedback in terms of doing so. What we were trying to get at was this whole idea of capturing content in a lightweight, simply way. That’s where we began to prototype it.

We invested extremely heavily in terms of prototyping and in doing so with full fidelity markups. We felt that this was something where the expectation in the space was such high fidelity tools that we didn’t want to skimp on creating lightweight markup. People wouldn’t really get a sense for what the solution was. So we went straight to full fidelity markups built in Sketch and actually, very quickly turned them into prototypes and envision.

Ravi: Got it.

Sachin: That way, we were doing customer development interviews where we were walking people through the product showing them some of the core experiences like adding a note, taking notes, viewing and searching notes. What we constantly did when we got additional feedback was rev that envisioned prototype by going back, modifying the screen, screening alternative versions or by simply adding detail in terms of interactions into it.

So what was fascinating is that we built out quite a detailed demo via our envision sketch and it got to the point, frankly, that some people that we’re showing this to they’re like, “Oh, wait. This is the real product. Your click through prototype is quite detailed here. I thought it was actually the full-on actual product.”

Ravi: We are at the phase where not a single line of cord has been written, right?

Sachin: That is correct.

Ravi: Wow! You and Ada were experts on all these US tools by yourselves.

Sachin: No. I actually spent a lot of time learning Sketch for the first time.

Ravi: Wow!

Sachin: While I knew a lot of the core design principles, I wasn’t particularly familiar with Sketch. So part of the Notejoy process was just learning a new tool set and fell in love with a lot of the design work. Sketch is just an amazing tool that I use on a daily basis.

Ravi: This is quite inspirational with what you are sharing. It seems like you actually got your hands dirty and you did everything right from the idea to building markups, to building prototypes. So you did not hire any US expert till now?

Sachin: That’s correct. I think one of the things that’s interesting is that I think it’s fascinating, sometimes people as entrepreneurs get this feedback that your job is all about hiring the best people and getting out of the way. I do think that eventually becomes the case as your startup starts to scale. I think that’s usually great advice post-product/market fit.

I think earlier on, it ends up being fairly important to be willing to get your hands dirty and to be involved in a deep way in all aspects of the product. Obviously, when you don’t have the skills, you need to fill them in. I think it’s possible to stretch yourself and build new discipline and capabilities in all these backed areas.

For me, I ended up taking on the role for Notejoy of product design and engineering and so have been focused on building out Notejoy product, building out the design like we talked about with Sketch and then ultimately, doing the engineering. Then Ada has been focused on growth marketing analytics, as well as all the other operations related to activities like finance, accounting, legal and that kind of stuff.

It’s one of these things that I think small teams can do more than what you expect and I’m always inspired by small teams that are able to get incredible leverage and we’re trying to live that as well.

Ravi: Excellent. Again, very, very inspirational. My next question is while you were doing getting all the feedback for your markups and prototypes from users, again, what was the dataset that convinced you? Is it sufficient or how much of the qualitative and quantitative data you thought was statistically significant for you to make decisions and go ahead with the decisions?”

Sachin: Yeah. So what was interesting is that we started parallel tracking, the prototyping that we were doing and the building of the product. What was happening was that our markups, our detailed design markups were always further along than obviously what we built in the product. Then we started actually building out the initial, what we called Notejoy Alpha, which was the earliest version of Notejoy. At the time, the tool was basically a lightweight personal note-taking app for the alpha release just to start building up the infrastructure and building out the key components of the product.

I think when we got to the point in the customer discovery interviews, where people are starting to see how the designs that we had developed for the product were more compelling than some of the tools that they were already using. That’s what we felt like, “Okay. Great.” They told us that they would prefer to use something like this as supposed to an Evernote or prefer to use something like this as supposed to a Google Docs or they can see how this might be lightweight enough to convince them to move content from email and Slack to it.

That’s when we knew we could really start investing and engineering and building out a prototype, an actual prototype because obviously, people may say these things, but who knows until they actually start using it on a regular basis.

We then at that point said, “Okay. We have enough validation that the concept was resonating and people saw what we were doing differently from a design perspective.” A lot of it was nuance of the user experience. Notejoy is built as a three-column layout with your libraries and notebooks on the left-hand size, your list of notes in the middle and then a preview pane to actually view your actual content.

What people realized was that as we went through it, a lot of the productivity from Notejoy is because of that lab. It’s productive like email is productive as supposed to something like Google Docs, where it’s actually quite slow. Anytime you click on a Google Doc and you open up, you wait about two plus seconds for the document to load. It’s painful to search. For example, imagine doing a searching for a keyword in Google Docs and you type in your keyword, you see a list of documents, you’re not seeing your keyword anywhere, so you don’t even know how your keyword relates to these documents.

So then you end up opening up multiple tabs of Google Docs. You wait two seconds for each tab to open up. Now, you’re sending the document and you’re like, “Wait a minute. My keyword is still not highlighted.” Now, you do a Ctrl+F to look for your keyword. The whole process of searching is so, so painful that people told us, “I use Google Docs search to get back to a document that I already know exists just by searching for the document title. I rarely use Google Docs search to attempt to find content that I don’t know exists. I wouldn’t search Google Docs to see if there’s any information on a topic because it’s so painful.

So that’s where we thought we could build a better search experience, something that mirrored email, which is actually a much more powerful search experience, where your keyword is highlighted, you have this preview pane that you can quickly scroll through to find the right content. We load it incredibly fast worrying about performance.

So some of those concepts, we could validate from the designs by showing people and I’m mentioning that this is how we’re different than some of those other tools. Obviously, not until they use it where they actually really, you start to believe that. That’s why we started building up prototypes, actual product and getting into the code.

Ravi: My question again back to validation, were you actually calling up people or sending them emails, have people sign up to help you out or how was it working out?

Sachin: We believed and it’s super important for us to try to meet people in person if we could. We actually have regular interviews with people all up and down the Bay Area. So we try to grab both individual contributors that were likely to be the bones using the tool on a regular basis. We’d grab more senior leaders within organization, which would likely be sponsoring it. We’d be going through the latest iteration of markups and then eventually going through the actual product with them to get their feedback.

It’s one of these things that we … Our bar was we wanted to continue to have interviews and successive ways of interviews until we felt like we were hearing the exact same thing every single time and not learning anything new. So what we do is we do these waves, where we do five interviews. We’d update and iterate on the concept, either the markups or the actual product and then we do another wave and would keep going until we felt like we were hearing the same thing.

Ravi: So when you talk about waves, you go to different people each time or the same people incrementally as you proceed with the designs?

Sachin: We actually went to different people each time until we had a launched product, where the people could be using it on a regular basis. We felt that just getting different people’s feedback and perspectives would be valuable because then not only are we iterating on the dimension of what we’re currently showing them, but also then we’re getting feedback on everything else. There’s the product/market fit hypotheses, whether it’s the overall concept and whether it resonates. So we try to get different people each time.

Ravi: Got it. Good. Once your design got validated, when did you and how did you hire your first set of developers?

Sachin: It turns out that we ended up just building it ourselves. I’ve actually done all the engineering for Notejoy across our web map, across our desktop apps for Mac and Windows, as well as our IOS app. That includes all the front end, as well as the backend.

Ravi: Sachin, this comes to me as a complete shocker. I didn’t realize that you are multidimensional and multi-talented. I do not know how product managers I know, product leaders I know who are full stack product leaders. Did you pick up the skills or were you good at it since the start?

Sachin: Yes. I mean, I’d say for me, I went to U Penn State computer science, as well as finance. It’s been interesting. Every corporate job I’ve had, I’ve always been a product leader. Then when I’ve done my previous startups, anywhere.FM, Connected and now, Notejoy, I’ve always been a hybrid product manager plus engineer. It turns out even when I was working at LinkedIn, I’d be coding on the side just managing personal projects just for fun.

For example, sachinrekhi.com is a CMS that I wrote myself not because there aren’t any … There’s lots of great CMS’s out there, but it was a way for me to learn new technology, built on a Python stack at the time. I was using Google App Engine, so I wanted to learn about that. So that’s one way I’ve kept my skills fresh.

I also have a to-list app called MonkeySort.com, which I use personally. Anyone can sign up. I’ve never promoted it, but it’s really just something that I use to learn new front end technologies, to improve my java script skills. I’ve kept the development up-to-date even when I was working in 100% product roles. Frankly, when I left LinkedIn, I was almost more in a GM role. So it was very different than my day-to-day, but it’s a fun passion area on the side.

Then when I started Notejoy, certainly spent a bunch of time really getting back into the technology stack. What we wanted to do was drive the technology stack based on key requirements, product requirements for Notejoy. We knew, for example, that user experience in a tool like this is paramount. This isn’t just about building some features and giving it to users because we’re in a very crowded existing market that building a high fidelity, great user experience was going to be really important.

We also knew that having apps in all platforms is a given in this day and age. One of the ways we believe would create productivity was by creating desktop apps, unlike Google Docs where you have to always go to a web browser, so it feels a little further away. We wanted something that lived on the desktop.

Finally, we wanted realtime editing capability just like Google Docs. That drove a lot of the technology investigations. So it’s amazing java script has moved, has gone so far with frameworks like React and React-Native, which enable you to build full fidelity desktop style applications, but using full web technology. Even React-Native lets you build mobile apps, but write them once across IOS and Android.

So that drove a lot of the decision of thinking around which front end technologies we’re going to use. Then because we knew we want to enable realtime editing, spend a lot of time looking at actually a technology called Operational Transformation, which is what Google Docs uses to enable their amazing realtime editing experience. That was a very fun exercise back to my computer science days of getting my hands dirty and some of the computer science stuff, which was a lot of fun.

Ravi: I’m curious to know how long did it take. Were you full-time working on this product or what were your other engagements? I’m just curious since I got to know so many other aspects of this from you. How was your other engagements?

Sachin: Yes. What was interesting about Notejoy was we started at two years ago. At the time, early on, obviously, and at that time it was full-time actually working on Notejoy. Early on, spent a lot of time on validation, but then quickly got into the engineering aspects, building up the product. I’d say in addition to that, I’m just a big believer in the product community, so spending a lot of time advising companies. I ended up advising 10 different startups, all early stage, seed-funded startups, helping them through product strategy.

Then that was just a fun way for me to get back into early stage startups since I spent the last four years at LinkedIn and wanted to really dive deep into the early startup world and then was continuing my efforts to blog. I think blogging has just always been a passion area of mine and wanted to really continue it. It’s become way harder since that we’ve launched the product to keep it up.

I’d say those are the other engagements, but outside of that, it was 100% full-time, spending most of my time on Notejoy, either talking to customers or designing or building the product and trying to be as productive as possible.

One of the biggest challenges with such a small team of just eight or nine is that you have to be insanely productive with your time because time can be easily wasted. So one of the tools and techniques I used was a tool called Rescue Time to literally track how I spend every minute on my computer. It turns out when I’m working most of the time, it’s either in front of a computer or with my laptop in front of a customer. So you can get pretty detailed analytics of how your time is being spent.

So I’d look at how much time I’m spending in design tools, how much time like Sketch and envision, how much time I’m spending in all my engineering tools, how much time I’m spending using Notejoy, our early prototype and then eventually the final product. Comparing those productive tasks to time I was spending doing things like email or time spending on social media or time spent on entertainment and constantly reflecting every week when I got my summary how could move more of my time to the productive tasks and less of my time to the unproductive tasks.

Ravi: I can understand your passion towards technology and your oz to build it all by yourself, but did you not feel at any given point of time hiring somebody who knew this technologies well would be a better investment of your time because you could have built it much faster or what was the drive? What was your motivation otherwise to try it all by yourself?

Sachin: I think it’s one of these things where our philosophy has been to keep the team small prior to product/market fit, but then post-product/market fit, we think it certainly makes sense to hire additional engineers, build out the team and what not. Part of the rationale there is that you spend a lot of time iterating in the earliest stage of a startup. We could show a concept to someone, even build it out in the prototype and then iterate very quickly and we ultimately decide actually, this is a very different direction that we want to go in now that we’ve gotten feedback from people.

You’re changing direction on a dime based on validated feedback, but that can be very jarring. So actually, we feel that it’s way quicker for us to mentally decide to move into different direction when it’s just eight or nine to be convinced as supposed to socializing it with a larger team. We also felt that the communication overhead is way lower when again, the product design and engineering is all in my head as supposed to communicating it with other people.

Ravi: Got it.

Sachin: I think there’s some advantages to actually moving fast when the team is small. It also was an artificial constraint on product development, which we thought was someone helpful. If all we kept hearing in terms of customer feedback was, “I can’t use Notejoy until it has the full kitchen sink in terms of every feature that, say, Google Docs had,” that tells you that you don’t have a compelling differentiation. So we knew if that was going to be the answer, that’s not the game we were going to ever win and certainly not the way to build a differentiated product.

So by having this constraint of like, “Okay. Well, we have a pretty good clip on engineering, but we’re not going to be able to build everything,” it helped us focus on the real differentiators as supposed to constantly building a functionality that people are claiming that they want.

Ravi: Got it. My next question here is on deciding the scope of your features for your first release, right? While you were building in the last two years, when did you finally think that, “This is my minimum feature set that would be good enough for a first release”?

Sachin: Yeah, great question. I was eluding to this earlier where I said that we ended up having an alpha, beta, gamma and v1 release. The v1 release was the one that we just released in December, so about two years later. What’s interesting is that the alpha release, Notejoy Alpha, we actually released in three months after we started Notejoy.

At the time, that was a very, very lightweight note-taking application that was purely for personal productivity. The goal there was really just start getting the engineering working, trying to get a product that worked. We did spend a lot of time on performance to try to make it super fast and lightweight. So that was the alpha release. We only had about a dozen people using it.

Frankly, almost all of it was family. My brother was on it in the early days. We had a couple of good friends using it. There really wasn’t much compelling reason to use it at the time other than, “Here’s a clean, simple, note-taking application that you might want to use,” but it was important for us to getting usage. We, Ada and I, started moving a lot of our documents to it.

So part of the rationale there was to just start getting something going and getting some feedback on it. We then did our beta release and that was about six months after that. The beta release was actually one where now we’ve got ultimately in successive waves about 100 users on it. With the beta release, at this point, we had some of the key team collaboration functionality of Notejoy. This included realtime editing. It included what we call the Chatter Sidebar with the Notejoy, which lets you see who’s viewed your note, lets you have lightweight reactions, as well as full-on thread conversations with the Notejoy. Now, you can really start using Notejoy as a team.

So we started onboarding teams very carefully into the Notejoy Beta. The idea there was, “Hey, let’s go take this to some small teams. See if we can convince them to try to use it. We’ll walk them through a one-hour detailed demo of the product, answer their questions.” As a part of that process, trying to get them to commit to at least trying it for a week with some notes or some part of their team.

When we started that beta process and that beta process was interesting because we really held the gate at, “Can we exit the beta as we need retained users?” At the alpha stage, these folks were our friends. It was very clear that people would just stop using the product and not continue to use it. With the early beta, I’d say that was still the case. When we first launched the beta, we had a couple of people using it, but then ultimately, they started dropping out and they were like, “Sachin, this is great, but I just can’t convince myself to use this over Google Docs. I can’t convince the team.”

We’re like, “Okay. We’re certainly not ready to launch publicly until we really have teams that will retain and using Notejoy in a weekly basis.” That’s when we kept iterating both in terms of the product to fill in the gaps on the issues that they were experiencing, but also bringing on new teams. So our goal was can we get five new teams each week to start using Notejoy through this onboarding process and continue doing that.

We ultimately had the beta and gamma for I’d say nearly nine months before we actually publicly launched. In that time period, what we were doing was constantly iterating on the product. We got to the point we were really co-creating our product with our top users. We had this great company called Kinnek out in New York City, which was a funded startup with about 60 employees using Notejoy. The CEO, Karthik, was super passionate about the space of capturing institutional knowledge for his team because he felt like he was spending so much time reeducating his team on things and when employees left, it felt like there’s a lot of information lost.

So he was super excited about Notejoy. Once we got him as one of our first beta users, I would get daily, if not, multiple times a day emails from him just telling me like, “Hey, this is cool, but I ran into this problem. Here’s this bug that I hit. You know what would be really cool? If you added this feature. I can’t convince this team to use this until you add this set of features.”

We realized that that depth of interaction with a few companies was far more valuable than launching it and releasing it to hundreds and thousands of users because we were getting such high fidelity feedback. As we continued to iterate, we had other customers that looked a lot like that. There’s this company out in Austin, Texas called Wikibuy and two great guys, Walt and Adam, who were senior leaders of the organization, took a liking in Notejoy and again, would send us weekly detailed feedback.

Adam, for example, would even do these lightweight markups and give me ideas on how to improve the product. The learning was so accelerated because of the fact that we were working so closely with these guys in this co-creation way.

Ravi: Got it. Beta was done and then came … So walk me through the next phase from beta to the final release, the version one.

Sachin: Yeah. We were debating, actually, for quite a bit, “Do we just release beta?” A lot of people actually told us, “Hey, I’m using the product on a daily basis. This is way more polished than most products I’ve seen. So why don’t you launch? You guys are holding off way longer than most other teams.” So we had that debate. You know what we realized was that as soon as you launch, your focus always shifts dramatically to growing the site, growing your audience. We thought there was an opportunity in our gamma release to add a ton of additional functionality to deepen the product for a variety of used cases.

A lot of it was really about the onboarding, where the product worked great when Ada and I went and demoed a user on the product. If we just handed you Notejoy.com and you signed up, what we were noticing as we started to do that with some of our later beta users was a lot of people didn’t get it. They’re like, “What’s the difference between this and some of the other tools I’m using?”

Ravi: I also thought the same.

Sachin: It was like, “Okay. There’s a lot we could do to improve the onboarding experience to solve for that.” So we did things like create a video for Notejoy to give you a quick sense of what Notejoy is all about. We tried to move you further down the funnel within Notejoy in terms of helping you to invite other users, but also to … We have a welcome note in Notejoy that gives you a sense of what the product is about.

So we thought that there was an opportunity to improve that. Frankly, there’s still so, so much more to do to improve that, but we felt like we weren’t yet there in terms of minimum bar. So we added that in terms of the gamma release.

The other big area we kept getting pushback was this idea that, “I can’t imagine doing a wholesale move of all my content into Notejoy and since I can’t do that, it feels like using Notejoy plus Google Docs could be very painful.” That’s when we ultimately decided that we really needed to deepen our integrations with the workflow tools that people were already using.

We did this in two ways. One was building out a deep Slack integration, where within Notejoy, you can take any note and share it out to Slack and you’ll get a rich preview within Slack. Within Slack, you can grab a set of Slack messages and convert them to a note. You can even socialize content in Notejoy in Slack. Let’s say you have a product channel and a product notebook, we’ll automatically share on a daily or weekly basis the top note within Notejoy back out to Slack.

That was the depth we needed we felt to make Notejoy work really well with Slack, but we also wanted Notejoy to work really well with the entire G Suite and Microsoft Office. So we actually built a fairly deep integration with G Suite. You can sign up for Notejoy with your Google account, either your personal Google or your G Suite account. You can embed a Google document, either a Google Docs spreadsheet or PowerPoint right within Notejoy. We’ll give you a rich viewer of that content and then we’ll give you a deep link if you want to go back out to G Suite to go edit that document. We did the exact same thing for Microsoft Office documents.

What was important was that we wanted it to feel like our ideas that we’re never going to replace Google Docs. There’s a really great space for that, but we wanted to work really well with it. That was really interesting because it removed a lot of the adoption bloggers to why people wouldn’t try Notejoy. When they realize that Notejoy could really be almost this hub of content, not only do you have content that you create in Notejoy, but it can help you organize a lot of the content that exists elsewhere almost like a confluence or another Wiki-style tool. We realized that unlocked a lot of opportunities and helped solve a lot of objections.

So we decided that while we thought we could start getting users on Notejoy like the early customers that we had at Kinnek or Wikibuy and what not, we felt like these adoption bloggers we were hearing very frequently. So we wanted to really solve them before we launch more broadly. That’s what became the gamma release. As I said, there was a big debate internally. Do we focus time on this or do we just get it out there? We decided it was super important for us to try to solve for it before getting it out there because I think it was also this fascinating lesson, where we had talked to a lot of Quip users, which is another tool in the space and they had told us that they tried it and dismissed it and moved on.

When we got into the weeds on some of the reasons they dismissed the product, it turned out the rationale for dismissing it was actually based on features that Quip ultimately added in the product later on. So what we realized with a tool like Notejoy is people will give you a try, but they rarely come back and give you a second or third or fourth look.

So we wanted to make sure that when the broad set of users were looking at Notejoy, it felt like a fairly compelling product as supposed to just an early prototype. We felt like we could do that because we were certainly still getting feedback on a daily basis from users because of all our beta, gamma releases, but we were just holding off on the broader base launch.

Ravi: Got it. Were you also trying to get feedback internally within the product feedback or was it an external channel where they would write you feedback on email or something of that sort?

Sachin: Yes. Definitely, the product as well. During this phase when we were in the beta, there was a feedback link in the product. You can click it and then it will immediately just send us an email. We were super quick to reply to those emails, usually within an hour because then they turn in to these interesting threads of conversation. We’d often take people’s feedback and be like, “Hey, mind if we get on a quick phone call to come talk more about this?”

What we realized was that there’s always a set of users that are excited to co-create and co-develop a product with you. We identified those folks early and spent the majority of our time with them because they were giving us, they’re willing to put in the time. That being said, we also continued to get feedback from lots of other people, so we need to make sure we weren’t advising too heavily to a small set.

Ravi: Got it. My next question is on adoption bloggers you were talking about. So your product segment is high sticky segment, right? Because there are so many existing players and there are so many people using products their own way and they have already built habits. So what I mean by high sticky is with usage, users build habits and that gets trended with time. To break that habit and persuade them to try a new product in a new market is a Herculean effort, right? How did you pay attention to that? There’s another concept of, say, 9x times. Your product has to be nine times better than the existing product because three times is the pull of the existing product and the other three is the push of the new product, right? Did you see this as a big hurdle to help people push and adopt product?

Sachin: Definitely. I think this is definitely one of the biggest challenges that we face on a day-to-day basis that when you’re using existing collaboration tools within an organization, they become incredibly sticky because everyone’s already on them. All of your content is already in them and people are used to using them. Oftentimes, people have tried a lot of new tools and they start to get weary after doing so because they realize, “Okay. Well, I might like this one aspect of it. It certainly doesn’t have all the features that I expect and that the team is ultimately going to need.”

So that was a challenge that we knew we had from the very, very beginning. We actually think it’s one of the main reasons that Google Docs and Microsoft Office still end up being the predominant document collaboration tools and despite lots and lots of startups trying it, most companies just find that Google Docs is good enough.

That’s where we spend a lot of time thinking about how we’re going to actually get over this. There’s a couple of things that we ended up thinking about to try to solve this challenge. The first was we actually built Notejoy in such a way that it’s both a great personal note-taking tool as it is a great team collaboration tool. We actually have a lot of people using Notejoy purely as a personal productivity tool and say full-on Evernote replacement for them. They find it to be a lot slicker, faster, easier to use, more beautiful, more elegant than Evernote.

So that was something that we felt we could do to drive adoption with individuals and then over time, get the adoption with teams, but then still start to build an audience amongst these individual users that are using it. So that was one of the key strategies to really try to solve for this.

Another piece of it was we knew early on we are going to have to go after that early adopter segment that’s willing to try new tools, that enjoys trying new tools, that doesn’t mind imposing a new tool on their team because those are the only ones that are going to be able to really take that leap of faith early on. Then over time, our strategy would be specifically to build social proof for these organizations, to get them to be evangelists of ours, create case studies and then use that social proof when we’re talking to more early majority users that are a little bit more traditional and skeptical of, “Should I use this new tool?”

We’ve done that quite a bit, where now we’re at the phase where anytime we’re having a conversation, we’re constantly bringing up some of these great case studies we have and have gotten to the point where we have testimonials, we have detailed case studies, we have scenarios. We even have willingness from our existing customers to talk to prospects if they like on this.

Ravi: Got it.

Sachin: So those are some of the things that we’ve realized are important to help us get the trial in the first place. Then what’s interesting about it is that if we can ever get someone in the team to create content in Notejoy and then share it with their team, what’s fascinating about it is that Notejoy then becomes the sticky tool because there’s exclusive content that your team members can now only find in Notejoy.

Ravi: Got it.

Sachin: So if we can get you to that point, Notejoy ends up being quite stickier within that organization. The challenge is getting you to that point.

Ravi: Got it.

Sachin: That’s where we’re spending a lot of our time and how do we make that onboarding experience lightweight, how do we encourage you to invite people, how do we make it clear the value prop you’re getting. I’d say we still have lots of work to do to continue to refine that experience.

Ravi: Got it. Thank you so much. My next question is eventually, how did you get your first customer? What was the process like? How and when did you look for that first customer and how did you get it?

Sachin: I’d say that once we started the beta, we had a bunch of teams starting to use Notejoy. This turned into tens of teams that were using it on a regular basis. With those teams, at the time we told them, “Hey, Notejoy is completely free. You’ll be able to completely use it for free for the life of the beta. Don’t worry about how much it costs, but we’re thinking ultimately this is going to be any other team collaboration tool that you’d expect in terms of a freemium offering with a monthly subscription.”

Then we started to get some requests that looked more from our highest engaged teams that were more detailed in requirements. For example, one of our users was like, “We love what you’re doing, but encryption ends up being super important for us.” For us, our thought was encryption would be something that’s important for a larger team, not smaller teams. So it’s just not a priority for us. We were trying to figure out, “Do we prioritize this?” We ultimately decided to use it as a test of modernization and we’re like, “Hey, this is not our short-term roadmap, but is this something you’d be willing to pay for?”

At that point, we actually started doing lightweight waves of validation on we’re going to create multiple skews of Notejoy. There’s going to be Notejoy Plus and Notejoy Premium. One at $10 a month, one at $15 a month and then obviously, there’ll be discounts for annual pricing. Would you be willing to pay for this if this was in the most expensive plan? The customer said, the team said, “Absolutely.” So we ended up building it because we’re like, “Okay. Now that we’re feeling pretty good on the beta that people will use this, we want to get some validation on whether people will pay for this.

So we ended up converting them as our first customer with actual encryption and a few other things. Then we started basically creating all of our new features specifically any of the Notejoy Plus or Premium plan and not giving them away the free plan. We started using that as the impetus to see whether people were going to pay and convert.

We kept it pretty organic. I’d say in the beta phase, we let the teams decide whether they had any interest in paying us. In the gamma phase, once we got there, it definitely was something that was upfront conversation with every customer we onboarded. “Here’s the free version. Here’s exactly what you get with the free version. It’s limited to 10 users. If you’re going to want more than 10 users, which all the teams we’re talking would, you’re going to have to pay for this price point.” So we used the gamma as the real validation points for modernization, but then ultimately built the premium skews at the tail end of the beta.

Ravi: Then who agreed to be your first customers?

Sachin: This is actually one of the early customers that we were using, Wikibuy, that we had as we were co-creating the product with them, they were super excited about continuing to use the product, but we’re just looking for some more enterprise gain features to continue to use it.

Ravi: Got it. Excellent. My next question was on the discipline of building. I think you covered that a bit, which is I wanted to know how did you ensure that your team was making progress everyday or every week, whether you’re following OKRs or stuff like that, but it seems like you answered that already.

Sachin: I’d say that we actually are big believers in OKRs as a process. So Ada and I have had quarterly OKRs since the beginning of Notejoy. Our perspective has always been to make them aggressive, conceive them as stretched goals, always created some innate or urgency on making us feel always behind a little bit. We thought that was super helpful.

I’m a big believer of the OKR process partly because we use it as an opportunity at the end of the quarter to do postmortems, to simply look back on, “Hey, here’s what we set out to do. Did we accomplish it? Even if we accomplished it, did it ultimately achieved the metric results we’re trying to achieve?” Early on, all those metric results were about engagement. Now, many of those metric results have shifted towards growth and acquisition.

Ravi: Great. Thank you. My next question is on pricing. Is there any signs to that or did you just come up with numbers? How an entrepreneur who has just come up with a product, should he teach himself on pricing strategies or there is no rocket science there and you can actually start it simple? What are your thoughts around it?

Sachin: I think it comes down to whether you believe pricing is going to be a core differentiator for your business or not. What we believe was that for us, the core differentiation is mostly user experience. If we can convince you to use the product, then we thought the traditional pricing models in the industry would work. So that was the mental model that we were going with.

We ended up trying to survey all the existing tools that we thought were in the broad base collaboration space, whether it was email, whether it was group messaging, whether it’s document collaboration or project management and really look at the price points of these tools. We found that most of them were either three-day free trials or freemium products and then they had usually price points in the $5-$25 per user per month.

Then we thought the closest comp for us was going to be document collaboration tools. We looked at the $5-$10 per user per month price points in that space. So that’s what we settled on. We didn’t want to spend too much time on pricing early because like I said, we didn’t think it was a differentiator. I’d say one of the biggest challenges we’ve had with pricing is that even though people are spending this money on existing tools like Google Docs and Microsoft Office, as we said, this would always be incremental spend. We’re not going to replace those tools. This would be additional spend that you do in addition to those tools.

So what we’re finding is that we end up being more substitutional to tools like Wikis that we’ve certainly had people move away from compliments in Google sites to Notejoy. We’re more additional when it comes to thinking about using a tool like Google Docs or Microsoft Office. So it’s now made us realize that from that perspective, the pricing looks like premium pricing because now it’s something new that you have to buy as supposed to something you have to replace.

I think we’ll continue to iterate on pricing. My guidance, though, is that I think finding, ensuring willingness to pay us there is super important. We thought that intuitively, but then we also validated that with all the customers we now have paying us, but I think depending on how risky you think that assumption is of whether people will be willing to pay for this. I think that should help you think about how much you want to spend time on pricing strategy upfront.

With my previous startup, Connected in the personal relationship management space, we were very unclear on whether people would be willing to pay for it. So we had a very aggressive 14-day free trial, $10 per user per month afterwards. Then ultimately, we required three different price points because we wanted to see whether people are willing to pay because our worry was that people would love to use these kind of tools, but not be willing to pay for it. In this case, we didn’t have that concern.

Ravi: So you do not have free trial for this? There’s basic, free and then you upgrade.

Sachin: Yup. It’s freemium. I think that debate around free trial versus freemium is something we’re still having. I think ultimately, we might explore both models. Our thought was that today we went with freemium with the core upgrade trigger being if you want to use it with more than 10 people, now it’s time to upgrade. I’d say the interesting insight from that has been that we have lots of small teams that are loving Notejoy, that are under the 10-user limit, that are some of our most engaged users and using it everyday.

So we do feel as if there’s a missed opportunity to monetize those users. So we’ve been working on creating more compelling reasons to upgrade to Notejoy. For example, we just introduced the ability to have comment-only or view-only users in Notejoy. So if you want to share notes broadly with your team, but only have them on comment-only or view-only, that requires Notejoy Plus or Premium.

We also have the ability to recover deleted files that we just launched last week, which requires Notejoy Premium. We’re about to launch version history, so you can look back on previous notes and the history of that note and that again is going to be in the premium version. So the idea is that we think over time we’ll create more compelling reasons for people to upgrade to a newer version, to the premium version other than simply hitting the 10-user limit.

Ravi: Also, having a free trial gets them to try out all these great features, right? If they are locked and they have not used it, it becomes difficult for them to imagine what the benefits are, reading through the feature list only. So maybe that is also an incentive for you to try a free trial for a month or so. Anyways-

Sachin: Yeah, exactly. That’s definitely something we’re debating.

Ravi: Excellent. Great. My next question is on your emotional journey. I’ll ask it because building something from scratch and then waiting for two years to see it actually go to market, it’s not an easy task and not for the fainthearted, actually, especially who has something. I do not know how you manage to keep your sanity, but I’m very curious to know what was your emotional journey curve all through this. When did you go into the low phases and when were you high? If you can just go through that in the last two years, that would be really, really helpful to us.

Sachin: Yeah, definitely. I think it’s been a fascinating journey and we’ve had some incredible lows and incredible highs. Probably the most memorable ones actually often came back to customers that we were working with that just surprised us. What I mean by that is we’d go meet with a customer, we have a potential prospect, we’d have an incredible hour-long demo, sometimes they overextend the two hours because they were so excited about working with us. You could see how passionate they were about the problem space and how it resonated based on what they saw.

We felt like we were co-creating in terms of getting features requests from them. Then it falls flat on its face in terms of usage. We were seeing this that no one ends up using it. They don’t really end up adopting it. We hit them up and say, “Hey, what happened?” They’re like, “Oh, it just didn’t really work with our workflow.” Those have been some of the most low lows that we’ve ever had because we thought we were expecting that this was a winner, this one was intuitively understand and resonate our product and it just wasn’t the case.

Those are top … I think it ends up being a case and you’re like, “Oh, we’re headed in the right direction. Is this really even going to work?” When that happens, I think part of the benefit of having gone through two previous startups where the emotional journeys were even crazier is it gives you a little bit of perspective of you’re not going to win every customer and that’s fine and trying to deal with it from the perspective of being like, “Okay. Let’s go back to our metrics. How are we doing overall? What are we going to do next in terms of trying to improve the situation of the product?”

What funny is that we’ve had some of the biggest highs in the complete opposite case. We’d meet with a customer, we give them a demo and we get such a lukewarm response. They’re like, “Okay. This is interesting, but we’re committed to our existing tool set.” Then we start seeing in the metrics, “Man, these guys are on it everyday. Man, they started growing the number of users.” Probably the highest high we had was Ada was catching up with one of our friends and just mentioned Notejoy and gave them a quick 20-minute demo because that’s all the time they had and he’s like, “Cool. I’ll check it out.” Started using it internally, actually in a product used case, where one of his product managers on his team was starting a new project and used Notejoy for it. Started doing all the customer interview notes in Notejoy.

What they realized was that Notejoy was a great place to share all the individual detail of customer interview notes. What they used to do was that they put the summary in a Google Doc, but no one would ever see the raw notes. Now, they have the summary and the raw notes in Notejoy. Then ultimately, they invited the designers that they were working with to check out these comments around the customer interviews. They started uploading their designs to Notejoy. Then the R&D team was using it and then just virally, the entire 30% company was using Notejoy on a regular basis. That was super exciting for us to see this really organic bottoms up virality happen and spread throughout through the organization. This time unlike prior times not being led by a key decision maker or CEO or an executive.

I’d say that was probably the highest moment where we’re like, “Maybe we can recreate that Slack-style bottoms up rally with Notejoy because we’ve seen it happen.” So I think it’s one of these things we’re like, “Okay. Well, we shouldn’t get too excited to. This is just one company, one anecdote. Can we repeat it?” So we try to dampen the highs and dampen the lows to make it more successful. I think a lot of it is emotional roller coaster. I think in our space specifically, we constantly kept … I remember when we were in the gamma phase, we’re already over a year and a half in in developing this product and we were getting antsy, starting to go like, “Should we launch? Should we launch? Should we just launch this thing?” We kept talking to customers and they’re like, “Well, I could see myself using this, but I need feature X. I could see myself using this, but I need feature Y.”

Sometimes it just felt like there’s an endless loop of features that we would need to make Notejoy compelling. So I think that was certainly some of the lows as well, just feeling like it’s never going to be good enough to compete in the space. We’d go back to some of our most engaged users and be like, “Look, these guys are already super engaged.” When we looked at our DAU/MAU ratios, we were 25+% for DAU/MAU engagement, which is best in class, in fact, for SaaS software. So we tried to use some of those metrics to give us the perspective of something is working here and it does make sense to eventually launch it once we feel we’re ready.

Ravi: I’ll come to metrics. In this journey that you just mentioned, did you ever feel like giving up that it is not going anywhere or did you have that positive frame of mind that you want to see it succeed or did you give up any or did you feel like giving up at any given point?

Sachin: Yeah. I’d say that a lot of that emotional journey we went through when starting Notejoy in the first place. So when we were thinking about what next to do in our career, especially me, I’ve worked on several startups in the past. I’ve been a product executive at larger companies as well. For me, a lot of it was I want to work on something that I’m deeply passionate about and ideally find something that’s successful, it could be my forever company, the thing I can work on the rest of my life.

I’m technically a serial entrepreneur, but not because I want to be, but it’s because the other startups haven’t yet gotten to the point where I can imagine doing them for the rest of my life. When thinking through that, I told myself that this area is one of the hardest areas to build a startup in, but the area that I’m absolutely passionate about. So really from a regret realization perspective, thought about, “I’m going to give myself several good years to try to make this work before giving up because I would certainly regret it if I didn’t give myself that space and time and that longterm view to try to make it work.”

So I think that perspective really made it so that I in the short-term wasn’t so worried about, “Oh, should I move on to the next thing?” Because every time I thought about it, I was like, “Well, what else would I be doing?” There’s lots of other great things I could be doing, but I’d be far more passionate about this if it works as supposed to moving on to the next thing.

I think one of the ways I did that was actually creating a list. I have this career plan, A through Z. It details if I weren’t doing Notejoy in its current form, what would I be doing? It literally has about 10 things on here’s the next thing I’d do. The first couple are pivots for Notejoy, ways we could pivot Notejoy, if Notejoy doesn’t work to try to make it work. Others are starting a new company. Others are going back and being a product executive or a CEO at a company. Others are full-time blogging and spending more time on that.

I thought having that career plan A through Z very detailed in a very detailed way made it very easy for me to always come back and say, “You know what? This is exactly what I want to do if I can make it work.” So if I can make Notejoy work, this is the thing I’d be happiest doing. I didn’t really suffer from the grass is greener syndrome because I had fully explored what was on the other side of it.

So I think that’s part of the emotional journey for me that’s helped ensure that at no point I’ve really said, “Okay. It’s time to give up,” because we’ve had this longterm view on thinking, “We want to spend years trying to make this work.”

Ravi: One dilemma and most entrepreneurs have, especially when they are struggling is they do not know at what point of time should they decide that they’re not going anywhere, the product is not going anywhere. Till what time should they persevere and see that there is chance and they should invest more? There comes a point of time where they decide they should pull the plug and say, “No, this is not going anywhere.” Do yo have any thoughts around that?

Sachin: Yeah, it’s a great question. I think the best way to think about it is when you have identified something that’s not working, usually it’s either product/market fit or growth, depending on the stage of the company that you’re in. You look at it and you say, “Okay. Great. This isn’t working.” You brainstorm and prioritize the top set of things that you believe will rectify it. Once you run through a bunch of the top initiatives that you think are the needle-movers and seen that none of them are really changing the needle, that’s when it starts to come back to the point where you have to really question your fundamental assumptions.

Once you’re feeling like you’re hitting your head against the wall, trying all these things, but you’re only getting small incremental improvements, but you need a magnitude level of improvement to change the structure of the business, I think that’s really the point when you want to be like, “Should we pivot more dramatically or frankly move on from this opportunity?” I think that how long those cycles are is dependent on the funding situation of the team, how quickly they can try out various potential iterations or improvements or initiatives to actually get the business back on track, but at least, that’s the mental framework I’d be using.

Ravi: Excellent. We are heading towards the end of this conversation. It’s been fascinating, one hour and 45 minutes already. What is the next step here? You achieved your product/solution fit and now you’re getting traction. How would you know when you will achieve your product/market fit?

Sachin: That’s a great question and one that we’re constantly debating. I think there’s a bunch of health indicators that we’re constantly looking at to understand product/market fit. We have an NPS survey that we run for Notejoy using Wootric. Basically, two weeks after you’ve adopted Notejoy, you’ll get a prompt to actually give Notejoy an NPS rating, as well as give verbatims. That’s been a huge source of regular feedback.

We use that as a key dimension of understanding product/market fit. We were pretty happy with it so far. We have about plus 30 NPS, which is great given that we only launched recently. So that’s been a strong indicator.

The other one that we’re constantly looking at is engagement retention. DAU/MAU is something in the engagement metric and retention just being looking at our cohorts to make sure that they’re leveling off. That gives us a sense that as new users are constantly coming in each week at the top of the funnel, are they sticky and are they staying? Does the product have staying power? We’re feeling pretty good about that as well.

Organic adoption is probably the third one that’s worth mentioning that obviously, we’re going to spend a lot of time on user acquisition and growth, but for you to feel like you have product/market fit, you want to know that there’s at least some word of mouth happening, where people are telling their friends about it and then their friends are trying it out as supposed to seeing it through some specific viral or channel or other paid channel. We’re finding that we do have some organic growth happening. So we’re feeling pretty good about that.

I’d say that from one dimension, from the metrics it’s like, “Okay. That’s interesting.” The core product has staying power. People are pretty happy with it and we’re getting new people to come in. I’d say what’s interesting about it is I wouldn’t say that we have product/market fit for a specific audience just yet because we can’t yet identify that core audience for which Notejoy is always going to tend to resonate more often than not.

What I mean by that is initially, we were thinking startups, R&D teams and marketing teams and certainly, we have a lot of those teams using us and enjoying us, but what’s been fascinating is since launching is we’ve had a bunch of new customer segments that are even more deeply engaged and quicker to adopt and to drive adoption within their organizations. A lot of freelancers and agencies, for example, are using Notejoy very regularly with their marketing agency, digital agency. We’re like, “Oh, that’s interesting.”

So when we think about how do we put Notejoy in front of a repeatable, findable and scalable audience for which we can constantly get drop them on Notejoy and continue to see regular NPS, regular strong engagement retention, that’s really the interesting calculus that we’re going through now, identifying those teams, figuring out how do we reach those teams and then how do we ensure that when we reach them they, in fact, exhibit the kind of engagement retention that is indicative of a strong product/market fit.

We’re spending a lot of time on that. I think it’s one of these interesting challenges where there’s no easy answer. Part of it is we spend time thinking about some of these target segments that have a lot of engagement, but then you have to wonder how much modernization potential do they have or how findable and reachable they are. It’s this complex multi-varied equation of matching great audiences with a great product. That really is the challenge of product/market fit.

Ravi: My next question is on key metrics. The things is everyday, where are you spending your energies on? Which are the key metrics you’re keeping close eye on everyday?

Sachin: I’d say we basically have a core set of metrics that on the engagement side are looking at DAU/MAU in terms of detailed daily engagement. We look at weekly active users to make sure that that continues to grow. Then on the actual growth side, we’re looking at weekly signups and looking at the sources of those signups to understand where that traffic is coming from.

I’d say in addition to that, we have very specific actions that we’re excited about people doing within Notejoy. So note views and notes authored are key metrics that we have both on a per user basis, but also for aggregate cohorts of users because that gives us a real sense of … Notejoy is all about helping you create capture content and then helping you share it. Then the end result of that sharing is other people engaging with that content.

So the litmus test for depth of engagement for us is actually note views. Then also, we have key actions that are really about the social functionality and the product. While those we don’t look at on a daily basis, things like note reactions, note comments, note likes, they are certainly in our weekly dashboards that we’re checking on a weekly basis.

Ravi: Got it. What kind of analytics have you set up for your product?

Sachin: On the acquisition side, we’re using Google Analytics to be able to understand refers and different sources, but then it’s tied in to our own backend. So for the actual engagement metrics, we have a set of dashboards that we have built, Homebrew, so we can get at all of the detailed analytics on a per cohort basis. By cohort, most cases I mean from a per audience channel basis. So here’s the metrics for people who signed up from product hunt, here’s metrics from people who’ve signed up organically from homepage and what not.

We’ve actually built a three-key dashboards, an acquisition dashboard, an engagement dashboard and a modernization dashboard. We’re constantly iterating on what’s the most important information to put on there, but design it in such a way that those will be three things we look at every morning as supposed to we find that when we were looking at general tools like Google Analytics, Mixpanel and what not, oftentimes, you just look through a lot of things, but don’t have that beautiful dashboard that includes everything, not only recent activity, but also some of your metrics. So we felt the need to create that ourselves.

Ravi: Excellent. Last two questions here. What are your plans for … How do you invest in marketing? If an entrepreneur comes up with a new product by himself, what are the things that he should be doing to spread the word out? I mean, looking at your website, I can see that you have some very good references and testimonials from people like Andrew Chen, who just got really popular after Uber joining Andreessen Horowitz as a general partner. So getting these big names, does it help?

Sachin: Yeah. I’d say there’s been a couple of key strategies that we’ve used. One, certainly, is the blog I talked about, building your audience before you’re ready to launch. What was interesting about Notejoy was that Ada and I were debating, “Do we build a community around Notejoy?” What we decided was that early on, the best way to do this was to continue to invest in building Ada and I’s own communities. So obviously, I blog frequently on product management and all things related to product. Ada also blogs about marketing. So we decided to actually to continue to invest in building out those audiences. So continue to blog, continue to build followership on Twitter and Facebook.

So that ended up being the way that we continue to build an audience because it helped us create a great seed audience for Notejoy when we were ready to launch and an audience that we felt would be exact target customers since we believe that product teams and marketing teams and startups were a great audience for Notejoy.

That ended up being one of the key strategies we’re working on. We then spend a lot of time leveraging our network and our relationships with people here in Silicon Valley that we built over the last decade to identify all the early teams that would use Notejoy. Part of our goal was not only feedback, but actually trying to get customer testimonials like you mentioned from folks that were influencers in the industry, from companies and logos that we thought would be relevant.

So part of choosing the folks that we included in our beta and gamma was trying to optimize for that so that when we went out and did do our public launch, we weren’t just talking about our own usage of Notejoy or telling our own story, but in fact, we can have lots of other people do so.

So we even solicited product reviews from many of our top users for our product hunt. On product hunt, for example, you’ll see dozens of top users, whether it’s Kinnek or Wikibuy or Andrew Chen or lots of other folks here in the industry that could speak to the product and tell the story of Notejoy better than we could, which we felt was super important in the early stages of getting Notejoy out there.

Ravi: I also see the trend of getting published in a TechCrunch article. How does that work out and are you also thinking of doing the same?

Sachin: Yeah. I think press is definitely an important thing to do and we’re certainly going to be looking at doing that as well. I’d say the dynamics of the industry have changed quite a bit. We were quite happy with the initial product traffic that we got from product hunt in terms of new users and new customers. In our case, actually, product hunt is a great source of traffic because the audience does relate to the kinds of users that would use a team collaboration app like Notejoy. So that worked out well.

We found that we got a ton of traffic through our own social media, things like our blogging, but then also publishing the story of Notejoy on sachinrekhi.com, on Medium and on LinkedIn. I think the value of press has really changed quite a bit in terms of being a great place for new product launches. It’s far less interesting.

I think having a compelling trend piece on what’s going on in the industry ends up being far more interesting piece and frankly, a far better way to get press as well. I think it’s important to think about your press strategy, but frankly, if you’re betting your user acquisition on press, it’s not going to be sustainable, anyway.

Ravi: I see.

Sachin: So not an ultimate source of acquisition for a company.

Ravi: Those always get you those initial eyeballs, right? So that helps, right?

Sachin: Yeah, definitely helps. I’ve just been amazed because when I look at that compared to my last startup, Connected, we had press and TechCrunch, Mashable, all these sources, but the product hunt traffic is incredible that it makes up for far more traffic than all of these additional sources. I think that that dynamic has changed quite a bit.

Ravi: Tell me one thing, I mean, for those who are not familiar with product hunt, I would assume that product hunt is attractive to the rest of product builders or do you see that regular audience, regular users are also active there? Could you help understand how product hunt works for the general audience who may not be familiar with it?

Sachin: Yeah. So I’d say that product hunt is really a community of makers, to your point initially attracted folks that were also builders themselves. When you’re building a product for builders, which we are, in fact, doing with Notejoy, this is the SaaS part that you could use for your own startup, it ends up being a great audience specifically for that.

Ravi: Got it.

Sachin: What were finding, though, is that there’s also a bunch of enthusiasts now that are starting to follow product hunt, that are just excited about trying new tools. That ends up being an interesting audience for us as well. I mentioned earlier that we have a bunch of agencies using Notejoy and a lot of those guys were sourced initially from just individual team members within their team being product enthusiasts that followed product hunt, not builders in the traditional sense, but enthusiasts that follow that audience. So I think there’s some value there.

I think it largely depends on the product that you’re creating. There’s a lot of categories of software or products that you’re building that product hunt really isn’t your target audience. I think for us, though, it did work out quite well.

Ravi: Yes, I can understand. All right. My last question here is of all the lessons that you may have learned in this journey with Notejoy, what would be your biggest lesson or lessons, maybe one or two, that you want to pick?

Sachin: I think the biggest lesson, frankly, is almost like a meta lesson on advice. As you work on a startup, you’re going to get incredible advice from incredible leaders. The key thing to remember about advice is that even when it’s generalized, it’s anecdotal in nature. That advice might be about hire quickly and replace yourself as the CEO. It might be advice on how to price your product or how to go after the market or when to launch, launching early a product that you’re embarrassed about or really building out a minimum awesome product that is really polished in depth. A lot of the advice is contradictory.

What I’ve realized is that so much of it depends on the dynamics of the market that you’re in. It’s important to always gauge the feedback and look at feedback at who it’s coming from and what experiences they’re drawing from when giving you that feedback. Were they a brand new tool in a brand new market? The dynamics are very different. In that case, for example, I’d encourage you to get something out that you are embarrassed as quickly as possible to start learning.

When you’re in a crowded market, for example, the feedback, it should be the exact opposite of that. You need something compelling from day one. I think that nuance gets lost and I think we oftentimes in the product community have this superficial discussion of like, “No, you should launch a product that you’re embarrassed about,” or “No, it should be polished,” or somehow we’ve moved to a new phase where now it has to be this new thing, but it all comes down to the dynamics of the market.

I think some of the challenges of Notejoy are so different than the challenges of Connected, my previous started, because Connected was I’d say a more new market opportunity. Notejoy is a very much an existing market with incredibly strong incumbents. Being very careful and nuanced about how you interpret and take feedback and ensuring it applies to not only the stage of company you’re at, but in the dynamics of the market that you’re in is the real hard part about getting advice from advisers because it’s not easy to interpret.

Ravi: Excellent. Well, this brings us to the end of a fascinating conversation with Sachin. Sachin had promised me that he would do a two-hour long conversation because we really wanted to go deep into it and not just a superficial hour-long conversation about how he built Notejoy and he did really, really well. He helped me answer all the question that I had. I’m sure the audience would love this conversation. So I wish you all the best, Sachin, for the success of Notejoy and I’ll be somebody who’s looking keenly at how Notejoy grows and I’ll do my best to spread the word out as well.

Sachin: Awesome. Thank you. Really enjoyed the conversation today.

Ravi: Thank you again, Sachin. Bye-bye.