With new products, it is challenging to know what to build and when. How do you choose from the possibilities you have? How do you prioritise? When is data useful? When is it time to pivot? How much is good enough? Or simply, how do you get started in the first place?
In this talk, Varun shares his 0 to 1 playbook developed while building and selling his first company, shipping products for billions of users at Meta, and now creating a new B2B SaaS product for his new startup. Building a new product requires knowing when to leverage limited data, when to lean into your experience, when to question what you have learned, and when to start over. Whether you are a product lead, engineer, designer, or founder, this talk is for anyone involved in building and launching new products.
1 / 64 Use ← → to navigate
Auto-generated transcript - may contain errors.
Tap a timestamp to jump the video.
Hello and good afternoon. So we're here to talk about going from zero to one, getting a new product off the ground and really figuring things out when you don't know anything about what you're building, right at the early days. Many of the frameworks we use to develop products, often at a later stage, are useful at that point, but when you're starting off, there are lots of gaps that need to be filled, and that's what I'm going to do.
I'm going to lay the groundwork, talk about the challenges I've faced in doing this multiple times at startup scale, as well as a billion user scale at Meta, and I'll fit in as many examples as I can through my career, and hopefully it'll start to make a bit of sense.
But first, who am I? It's a good introduction for me, but this is really relevant to the stock, because I spent the first seven years of career in a completely different industry, in the music and advertising and film industry, doing very different things.
I had no plans to get into tech or start up a company, but I found myself doing just that. I learned to code, started up my first company back in twenty twelve. We were building games, technology for games in virtual reality. Around twenty fourteen, twenty fifteen was when we started finding product market fit, that just took off.
To cut a very, very long story short, we were then acquired by Meta, and at Meta I built up technology teams, and also shipped and built a lot of technology myself for billions of users across Meta's software and hardware product landscape. And now, when I'm working on my new startup, I'm going back to basics, trying to figure out what are the things that have worked in my career, what has not.
And this talk is really a distillation of my journey of going from zero to one many, many times over at a different at different scales and in different industries. Going from zero to one is building a viable new product for a new opportunity.
An initial success depends on these three things: your constraints, the type of product you're building, and your starting position. Regardless of the kind of product you're building, you will be limited by a bunch of things. Your constraints. So, resources to match your ambition, this could be time, people, money, quite often the technologies you need might not even exist yet, and the time you want, even the long even the most long running projects run out of money, run out of time, there is no magic money tree,
most of us can shake and fund the projects we want. And knowledge, expertise and experience. Even if you manage to hire the best people in the world, you'll run into challenges that will absolutely stump them, and they wouldn't know how to get past without figuring it out.
And you also, because you're building a new product from scratch, you don't have the hindsight and experience that you can rely on, even if you have experience in the industry. And while we'd all love to transform the world, the reality is that most of us build products that don't.
That's just the reality of it. And even leaps in progress can take a long time to saturate through a market. A really interesting stat that I came across recently is cloud infrastructure has been around for a long time now, but only fifteen percent of enterprise spending has moved to the cloud.
That just means there's so much more opportunity out there to build things that are meaningful. The type of product is usually a mix of whether your product is an abstraction or an optimization or some mix between them. You could be inventing a new paradigm, or you could be improving the status quo.
Optimizations typically start as small solutions to a niche problem, and then quickly become valuable. For example, you could be productizing a specific algorithm that could make a database really fast at a massive scale, or you could be improving the user experience for a product category that is much better than anything else out there.
Abstractions on the other hand connect lots of different pieces together, and make something meaningful out of it. So, it could be a product that combines data from lots of different sources and automates work between them, or something that many of us use today, a calendar app that synchronizes multiple calendars and allows people to book time.
So in this slide, a pulley is a good example of an optimization that helps you get access to water faster, and the tap is a good abstraction that hides away the complexities of plumbing and pipes and pumps and reservoirs. Where your product fits on this optimization and abstraction spectrum will impact how it is perceived, and how you position it in your market.
The third thing that determines your success is your starting position. You could be launching on an existing platform, or an existing family of products that already has users. So for example, launching Facebook Marketplace on Facebook provided access to billions of users who are already on the network.
This makes user acquisition easier, but causes other challenges. Because you're dealing at that large scale, even if you've just got thousands of users, it's harder to understand user needs at a granular scale. And quite often, the platform that you're building on will need to change, because you have requirements that your new product needs.
So, for example, launching a marketplace on a social network opens it up to spam and scam and abuse that you probably wouldn't have thought about. Inversely, building a brand new product, as you're building your product from scratch and you're speaking to users, you will have a granular understanding of what their needs are, but you won't have this large data set of information that you can base your decisions on.
And you'll often have conflicting options and opinions from which you need to choose from, and this makes it really hard. So they've both got challenges. But over the past couple of decades, we have landed on a bunch of best practices and playbooks and methodologies in which we use to build new products.
These are designed to maximize our chances of success, and for example, agile methodologies, build measure learn as an example, it has become pretty much the norm across the board. You build a piece of software, you test it with users, you learn, you build again, you run a marketing campaign, you measure its impact on the business, you run it again, you create, you design something, you run some user research sessions, you learn from it, and you design again.
But, being agile by itself does not help you get off the ground. It's only a methodology and not a process. So, how do you go from spotting an opportunity and building something that is useful, and then getting it into the hands of people to confirm that what you build is actually useful.
Before you become an agile builder, how do you get lots of people to just know what you're building and use it, and ultimately, how do you figure out who you're building for? And the typical process looks like this. You speak to people, you do user research, you build up confidence in what you're building, you build prototypes, you do some instrumentation, you analyze, and you go back to step one.
You just get this flywheel going. The hope is somewhere along this journey, you'll figure out a configuration of your product that works, and more importantly, sticks with users. For most startups, this takes the first few years of journey, and hopefully, they find something that works before they run out of money.
But the big challenge here is in keeping everyone and everything in sync, while having to constantly choose out of a billion options and decisions, almost like an infinite set of things. And then you somehow need to keep your teams and your company moving in the right direction as you're iterating through all of these different options.
And then somehow you need to consistently make good decisions. And to effectively manage this chaos, we've come up with lots of different things, right? So, we've come up with methodologies like scrum, and then we've got frameworks like jobs to be done, and we talk about feature experimentation, and data driven decision making, and a whole bunch of jargon.
But, these actually, at very early stage, cause more challenges. Because when you're trying to build a new product, there's so much that you don't know that often many of these frameworks end up crippling you. You're unable to make any decisions, let alone good decisions.
And there are three challenges that you face at this point. Finding the right people to test what you've built, prioritizing what you've built, and building a minimum viable product at the minimum viable quality. So let's dig into these. Finding the right people to test what you've built.
The first few users you usually reach out to when you're building a new product are usually in your professional or social circles or from an existing user base. Your experience, the size and quality of your net network will limit the kind of feedback you have access to.
So like any data set, it is really important that you don't draw wrong conclusions from a small data set, or you don't end up framing questions incorrectly. So, example, asking users like, do you like my prototype, or how do you use my prototype to get something done, or what you currently do to achieve something that my prototype is doing, will result in very different answers and very different conclusions.
But as you speak to people, you need to start bucketing what you're hearing into themes, And you'll know you've spoken to enough people when the themes start to repeat. This can take anywhere from tens to hundreds of people until you start to see the themes repeating.
And it really depends on your market and the product category. So here are my takeaways from dealing with this challenge. Takeaway number one, the outcome of research is not absolute certainty. Research builds confidence around a set of problems, or a set of assumptions, but does not ensure absolute certainty about the future.
Your data will be sparse, and crafting a credible narrative out of it will require a few cognitive leaps and big, sizable assumptions for you to make. At this stage, your opinions will be based on some evidence, but you'll just not have any certainty, and you'll have to make things up.
So what you should be doing is forming strong opinions backed by research and your own experience. The things that you hear, and this does not make research unuseful, it needs to help you form these opinions, and these strong opinions must be weakly held.
You should be willing to change your mind, and you should be willing to change your direction as you speak to learn people and learn new things. Because there's a problem of anchoring too quickly, and this is my second takeaway. At a really early stage when you don't know what's happening, you need to be aware of confirmation bias and subconsciously fitting what you're hearing to what you really want to believe in.
Be aware of spending time trying to fit things around your assumptions, and you could be fitting things to the outcomes you want without you really realizing it. And this is really important as a founder, because you spend so much time just trying to convince people to believe in what you're building, that it's really hard to correct for this bias.
So what you need to do is you need to assess feedback in the aggregate and find common themes. Don't anchor too much to what your first users say, because that's such a sparse, opinionated perspective, and you might actually need to speak to a lot more people and look at feedback in the aggregate to know where to anchor yourself.
And as you're sharing more feedback and assessing it, you need to look at your base assumptions. How much are you moving away from your base assumptions? And are you overcompensating for a single user, or are you spotting a pattern that requires you to completely change your direction?
You'll be the best judge for this, based on how deeply committed you are to the assumptions you made. The third takeaway is you need to be prepared for churn. You might hit the jackpot early and find really fast growth, but, you know, for most products that isn't true.
Because more often than not, as you're figuring things out, you will continue to churn through a lot of users. But what causes churn at this stage? We're not talking about churn at a growth stage, but this is really when you've got a handful of people.
It could be because your product is too much of a prototype, and does not solve the problem well enough. There could be a big requirement mismatch with the people you've spoken to, what you've pitched to them, and what they actually end up seeing in the product.
The features that they thought they wanted might not exist. Or there could be other barriers for adoption, compliance and security if you're in the B2B SaaS world, that could really inhibit people using your platform, or just dropping off it. And the last thing is, people are just busy, and this is common for a lot of products that you build today.
People just don't have the time. Tool fatigue is a real thing, so it's really hard to just get people to use something that you care passionately about. So your goal at this stage is to cut down on this churn as much as possible, and you need to do that by figuring out the right configuration of your product, building as much of it out as possible, and finding the segment of users for whom the product is at the right level of complexity.
So this only means that you need to continue building a pipeline, continue speaking to people, continuing to build inbound interest into your proposition. Because this is a rollercoaster ride of constantly trying to find suitable, a suitable market, a suitable product at the right maturity, and the right level of abstraction that you can get it out to users.
And if I think back to our first company ten years ago, we went through the first couple of years just churning through basically chaos of trying to figure out what worked. And we initially thought we were a technology licensing company, but it took us two years to figure out that it wasn't the technology that people cared about, it was the tools that we built on the technology that actually enabled them to do things that built the business.
And we wouldn't have found that out if we wouldn't have been through the ups and downs of just speaking to people, learning and constantly pivoting. I've spoken about finding the right people to test what he built, let's talk about prioritizing what to build.
This is when things get chaotic, because you need to make decisions, and that is always hard. And for most startups, this can lead to death by a thousand opportunities. Even if you're well funded, there are limitations. You can't build every single idea, you can't build every single feature, you can't test everything out.
You can't be indecisive. You need to make decisions. Because most tech products are made up of two components, the technologies and the interface. The interface could be an API, a software app, a hardware, piece of hardware. The technologies are all the components that make up and supports the interface.
So this actually results in two distinct kinds of work. Figuring out what that interface is, and figuring out what technologies you need to build to enable this interface. But quite often, at the early stage when you're figuring things out, the technologies need to stay slightly ahead of the curve, because you often need to build more technology than you expect, because the interface needs to constantly change and be reconfigured, and you need to have this library of options that you can choose from.
But you also don't want to build so much technology that it ends up becoming a dead weight on progress, and that you're just slowed down by things that you need to constantly maintain and test and try out. So, is a tricky balance, and here's what's worked for me.
Take away one, buy the things that make you move faster, but do not impose crippling limitations. So, for example, ten years ago, it was common for a start up to go and buy actual servers to deploy something, but today almost everyone uses the cloud to deploy their first product.
The reason for this is that it's much faster and just helps you get to people, get to people and learn things sooner. There will be many other things in your technology product stack that can benefit from this. A good example these days is authentication.
Almost nobody reinvents the whole authentication wheel because it's so complex, you can just pay an existing service to do it. But, there will be things that you need to invent and build, and those things should really matter for your business. So, for example, with my current startup, we tap and integrate into lots of APIs to pull data together and stitch it all for, and to make sense of all of this stitched information.
So we could pay for a service that does this, but we know that doing so will slow us down, because we have made assumptions now, but the assumptions will change, so our requirements from whatever service we use will change. The service will have challenges and its own bugs that we will inherit, and we might need a certain granularity of data access or other things that we might, change over time that would be hard for us to specify right now.
And ultimately, this technology is so critical to all of our assumptions, and everything we built is based on it, that we need to have the agency and the flexibility to move as fast as we want. So, does this mean that I need to go and, like, build my own database, because a database is so critical to what I do?
Absolutely not, because if the speed, unless, of course, the speed of accessing data is so critical to my company that I have to go and build something that nobody else has in the market today. But it's rare for such things to happen, and should always be weighed with business impact, and whether you have the capacity and need to do so.
Takeaway two, build to test your assumptions first. There will be certain parts of your tech stack that are tightly coupled with your business assumptions, as I just mentioned. So you need to micro pivot if you fail to build, or more importantly, to find, or just find that what you're building is not useful for people.
And this is when your assumptions will need to change, and you will need to just change your path until you find a path that works. And the only way you can do this is by standing up a bare prototype of your full working solution as quickly as possible.
Because the first thing you need to do is to test if it actually matches your expectations. So you need to build, rent, buy, do whatever you need to do to just get a working version of your product as quickly as possible. Takeaway three, you need to build things that you can throw away.
Cause you need to be prepared for your assumptions to change, your initial tech stack will change, your users will have different requirements, and some of your plans will just plainly not work out. In fact, most of your plans will not work out. But you'd have learnt new things from your users, from the people that you're speaking to, from the research you're doing, and from your market.
And you might also have unforeseen technical roadblocks that will require you to probably rewrite half the things that you've written. And teams struggle to find this balance. They either overinvest or underinvest in robustness and stability. The former leads to a drop in velocity, and the latter just leads to a ticking time bomb of debt.
And quite often it just leads to a bad product and people not really being excited to use what you've built. So real agility is not about slashing and burning your way through your product, but being really critical and selective about what you choose to invest in.
You need to be prepared to hack your way through your roadmap. Move pixels around, change your code, rework things if you have to. Of course, invest in important things, like maybe stabilizing your security infrastructure, if that's critical to your business, or investing in your design language upfront, but you should be prepared to throw things away.
So, with our current startup, we are in just year one, but every couple of months, we throw away vast amounts of code. It's easy, because it makes life easier for us, because we don't have to carry on this dead weight for months or even years, and we can just move faster and be hyper focused on what is important to ship.
Takeaway number three, you need to ship every two weeks. Regardless of what you're building, regardless of how long it takes, you should be shipping every two weeks, if not sooner. Don't plan for milestones that takes weeks or months or sometimes even years, with nothing that gets shipped in between.
Because if you don't have users, initially, you should be shipping for yourself, because that's when you'll find out that the best spec designs and the best laid out plans just don't work out. And the prototypes you build will feel different when you use them, and there will be a mismatch in expectations.
So these moments should be an opportunity for you to learn, and then tweak your roadmap accordingly. Does this, of course, mean that you need to only work on short term projects? Not at all, because even the most complex technical projects can be broken down and achieve small successes in two weeks.
Because you need to then collide with reality as often as possible, because there will be changes in user expectations, changes in design, changes in your code base, changes in your strategy, changes in everything around you, you need to constantly test what you're building with reality.
So, for example, we recently trained our own machine learning model with a new domain of data that we had no knowledge about. We had no idea how long it would take for us to get the results we wanted, so in the first two weeks, we created a really small data set, test data set, to see if it matched our expectations.
In parallel, in the same two weeks, we integrated a bunch of third party vendors who did something similar, just to see what it would feel like in the product. This helped us tweak the data set further in that same span of time, so that in the next sprint, could actually train our model, and we trained a very quick model, shipped it in our product, shipped it to actual users, so that we could get a sense of how it was being used, and whether it was actually matching our expectations.
That's when we found out that we had to improve the latency, we had a bunch of edge cases we hadn't thought about. We spent the next two weeks sprint addressing this. And by initially shipping it, it was far from perfect. It had lots of issues, but it gave us a good sense of what was really important to optimize for.
And we wouldn't have found this out if we would have waited six weeks to build the most perfect model that achieved the results that we hoped it would achieve because the expectations changed. We've spoken about finding the right people to test what you build and then prioritizing what to build.
Let's talk about building a minimum viable product at the minimum viable quality. Because most MVPs are not minimum viable products, but minimal working products. This is because it's really hard to know what viable means when you're starting to build a new product. Even if you have deep knowledge of your industry, you can write an extensive specification, there will be friction, and there will be mismatched expectations when people use it.
And the reason for being agile in the first place and shipping often is to close this expectation gap as quickly as possible. So rather than speaking to lots of people internally, especially if you're in a medium or larger sized company, about what the MVP should look like, you should be talking about how quickly you can qualitatively test the MVP.
Because defining the minimum viable quality of your product is not about how, not just about how pretty the pixels look, or how cool your design is, or how flashy the animations are, but it is about how well it does the job you have promised it will do.
Because it is very unlikely that with your very first prototype, you would have delivered one hundred percent of the promise that you cooked up in the first place. So you need to figure out with every iteration what that minimum threshold is for you to start delivering that value.
Because the initial process of finding product market fit is about you trying to figure out what this promise is. And there will be and this is when most startups figure out often too late that the problem is real, but the prototype or the product they've built just falls short of the promise.
So how can you end up building a minimum viable product at the minimum viable quality? First takeaway, quantify the gap between what you promise and what you deliver. The simplest test is to write down in a few sentences what your product is promising to deliver, and in the short term, how far you're going and actually delivering on the promise.
And even within this promise, what is your core value that you're delivering to your users? Are you planning to save them time? Are you planning to save them money? How far are you going and actually delivering on the promise? And as you make qualitative improvements, are you actually getting closer to delivering on the promise, and by how much?
Whatever it is that your MVP is doing, it should be starting to deliver incrementally on the promise. Here are a couple of tests that have worked for me. So for every feature, ask yourself whether you will miss it if you turn it off.
If your product is about building daily habits or any kind of habits, stop using it for a few days. Do you miss it yourself? Do you lose the habits that you've built? Now, do the same and ask these questions with your initial users.
In fact, the best test I have found is to ask my users whether what they would think or what they would do if I turn off certain features forever. That really leads to interesting, frank conversations about what they really use the product for.
The second takeaway is to find high quality feedback, because this helps you set the bar of what the minimum quality requirements are, and high quality feedback typically includes user stories, actual user context, and user opinions. It should be a bit bruising, because speaking to users and getting feedback is not about making yourself feel good, it's not about confirming your biases, it's not about just confirming that you're building the right thing, because unless you're actually getting bruised and feeling a bit bad, you aren't asking the right questions.
It should also help you strengthen or weaken your assumptions, because it can have an outsized impact on how you make other decisions downstream. And the last point should say, it should help you form opinions and make decisions. All of these together can be really strong indicators whether you're really getting good quality feedback or not.
It's not just about getting any feedback, but really finding these first few users who are willing to spend the time to give you high quality feedback. Takeaway three, research, data, reality are not equal. They're different things, and it's your job to reconcile them and make sense of it.
UXR, user research, is a good way to get an understanding of what your initial users feel, but the problem is at this stage you haven't even built your own product intuition, or don't even know what your customer segment might look like. You don't even know what a representative group of users even are for you to build a good group of people to test your product with.
Because in the early stages of a product, UXR will not give you a definitive answer, and will not translate into how people actually use your products over time, because so much is constantly changing. There's a big gap between what people perceive your product to be, what they perceive to be the utility and usefulness of it, how that maps into their daily habits, and most importantly, what they are doing to make time to use your product.
Very different things, and very different behaviors. For example, if you're building a product that is highly dependent on your user's data, so let's take Facebook as an example, right? We've got a network of friends, and it really depends on the information that that feed is pulling together.
If I show you a feed of somebody else's profile, it is almost meaningless, because it has no mapping to your understanding of the product. One way around this is to have simple instrumentation to get a sense of what reality looks like. And you need to be getting simple instrumentation into your product right from the very, very first prototype, because you need to understand whether people, when left alone by themselves, are using the product in the way you intended them to.
So at my current startup, we've cycled through various versions of our MVP, but right from day one, we've had very simple logging and instrumentation. It didn't take much effort. All we need are about five different events to get an understanding of whether the user's behavior matches our expectations, and that's when we know whether we're actually delivering on the promise or not.
Now, is a stark comparison to shipping something at Facebook scale. I still remember when I made a small improvement to a pipeline, just a few hundred milliseconds, but it had an outsized impact on user behavior on the product. These are not the kind of problems you deal at a startup scale, because you're not dealing with billions of users at big geographic scale.
And that's why you also don't need crazy analytics that do a bunch of things, you need something that is really simple, that gives you a sense of reality. So we've covered these challenges, and I'd like to conclude with ten things to remember. You need to bridge the gap between what you perceive to be the opportunity and what your users perceive to be the opportunity by building a product and getting it into their hands.
Frameworks aren't a silver bullet. They're a way to get things done, but they don't help you get started. What you need to do is to get the flywheel going. Speak to people, research, build prototypes, instrument and analyze, correct, change, continue on this process.
Because from this process of starting the flywheel, you need to form strong opinions that are weakly held, and then you need to change your mind because you need to invent and build the things that matter. And you need to do this by building a working prototype as soon as possible.
Get as much duct tape as you can together. Build, buy, rent, do what you have to to get a working product. Because then you'll learn things that will make you have to hack your roadmap, change your plans, throw code away, to ultimately get to the goal of shipping every two weeks, because that's when you really know whether you're delivering the promise.
Because when you collide with reality, you learn what people's expectations actually are from your product. And ultimately, need to reconcile all of these different things by building your own sense of reality between your own research, what you learn from your users, and the simple instrumentation you have in your product.
Because building a product from scratch is really, really hard. You've got a crazy number of directions you can go down, and you don't really know which one to start with. But the best thing you can do is to just build, ship, and test.
So with that, thank you, and good luck on your own journey.
