AMA: ezCater Director of Product, Delivery & Customer Success, Brandon Green on Building 0-1 Products

Not at all - it just changes how I think about product delivery and the tools my teams and I use. In the office, it was common to rally a bunch of teammates together in a "war room"-like setting, heads behind laptops and quickly bouncing status updates or ideas or urgent issues around to move a product forward. Now, we do that over Slack and/or Zoom. The main opportunity remote work has brought is a critical need for documentation - that is, an easily interpretable and navigable paper trail for decisions made along the product development lifecycle. In the office, decisions could be made in a meeting or a side conversation; if you forgot about a decision, you could always go ask someone in person. In remote work, you could do that (again, via Slack), but the expectation of a response has fundamentally changed. Slack is best used as an asynchronous communication channel, meaning that colleagues can respond when they choose. If you need information quickly, what better way to get what you need from the doc, Confluence page, or Slack thread where that decision was made? Straight from the source. Organizing all that information when building products is hard, and I have yet to find a single tool that is *amazing* at it (Abstract Notebooks was a product I worked on that did a pretty good job at addressing this!), but I do consider it a critical role as a PM to ensure that your partner team has all the context they need to build great things, and in a remote context that involves ensuring easy access to context and decisions that matter.

"0-1 product development" is the idea of building something from nothing. That is, you have an abstract customer or business problem you need to solve and no solution for it (0) and, as a PM, you need to figure out the first attempt at a solution (1) to address the problem. An example from my own career is Notebooks, a product I helped ship at Abstract - we had a meaningful number of customers abandoning our initial offering due to changes in the product design tooling landscape, and we needed to figure out what problems they still had that we could build a solution to address. After spending a good amount of time interviewing and researching the product landscape, we identified an unmet need (in that case, a way to centralize design decisions made in the product design process outside of the tool used for design, to easily communicate and ratify decisions among stakeholders). We built an MVP, validated it with customers in a controlled setting, and then iterated on that product until we felt it was ready for a public launch. My first step in developing a 0-1 product actually isn't developing at all - it's understanding or framing the customer problem. Often the problem is given to a PM in some other way that isn't actually the problem at its core. In the case of Abstract Notebooks, we actually had a business problem (customers were leaving our service because they no longer had an unmet need) but we didn't have a good sense of what other unsolved problems they had. In that case - and I'm a proponent of this - we went out and talked to users to help get an understanding of what problems they still had in their product design processes. We talked to a number of different kinds of users - former Abstract customers, curent ones, those who had never heard of us before - and started to find common challenges amongst them. That allowed us to shift away from thinking about the internal business problem to something very focused on the user. It certainly took some time to wrap our heads around a clear, focused problem we could solve, and there are a number of tactics one can use to do this (design sprints are one I like) - but that first step of beginning to frame the user problem is what I always find a useful starting point.

This is hard! For me, it's a mix of having a good understanding and confidence that you have (1) a clear hypothesis that you can test with a minimally viable product that is shaped by data and customer/market research, (2) confidence that you have a potential solution that can prove the hypothesis correct, and (3) an understanding of the risk and opportunity for building that solution, including the time it'll take to build, the availability of users willing to try your solution. When in doubt, it's always a helpful rule of thumb (in my opinion) to simplify the scope of your solution as much as possible, to both reduce engineering time/complexity AND to not squander the opportunity cost of shipping too late (see the Reid Hoffman quote question posted as well!). The hardest one in my opinion is 1 - making sure that you get down to the real essence of an unmet customer need and being incredibly clear and specific on how you think your product can solve it, and how you will know.

I don't think I have a great answer for this; I think there are a few possible points to consider though, and I think it ultimately comes down to how you understand the user/market problem your company is positioned to solve with its product(s). 1. Is that problem best solved by a single product, or does a group of products better address the problem or need? If so, how and why? 2. Is your product not serving the needs of your customers, and if not, why? Does the product have meaningful shortcomings affecting product-market fit, or is the market changing? (The latter was something we experienced directly at Abstract and caused us to explore a new product offering.) 3. What are other companies in the space shipping, and what does it say about their framing of the problem they're trying to solve? 4. Does your company feel you've delivered a mature, successful product to solve that main problem and you are eager to grow into a new market, solving a new and different problem? I hope this is a little bit helpful!

I think the quote has validity in some contexts and less in others. If you are building a 0-to-1 product in a company where the culture is anxious about, say, the brand impression your "embarrassing MVP" may invoke, that may be a fear you need to help alleviate as a PM. However, there are other contexts (eg. in financial products, healthcare tech, fortune-100 enterprise products) where an "embarrassing" MVP may actually compromise your ability to successfully validate the hypothesis of your MVP; for example, if the end-user highly values security, polish or simply need to trust the product to meet the unmet need, you may need to go a bit beyond "embarrassing" in your minimally-viable solution.

So, in my experience of building 0-to-1, I've never had to do this before exploring a potential new product 😅 and candidly, I really don't like doing it because any projections are in my experience educated guesses based on inherently flawed source data - historical data that may not apply anymore, all sorts of biases, differences between other products and your new product, etc. What I try to do instead of offering revenue projections is work with my leadership/stakeholders/et al to understand that the primary initial goal of shipping the MVP is to learn and validate. We can use other metrics to understand whether the product is viable (eg. repeat usage, engagement, etc. depending on the product's value proposition) and, in parallel, start to gauge what potential users are willing to pay for said product. Those two things together will help inform possible revenue projections.

I think the two most common mistakes in building 0-to-1 products are: 1. Not acknowledging or checking some assumptions about the problem your product is meant to solve 2. Over-investing in the first iteration of that product (the MVP) without having proven out the riskiest of your assumptions 3. Under-investing in product market research (specifically the other products in the problem space and their strengths/weaknesses) I see a lot of PMs attempt to build things that are bigger and more complicated than the most core thing they need to build to prove out whether a solution to the problem at hand is viable. This often manifests as other features that you may think are necessary, when in reality they are useful asides that don't actually get to the heart of what you are trying to prove out. The other side of this is knowing what makes YOUR solution unique in its ability to meet an otherwise unmet need. We see a lot of new products launch (eg. on Product Hunt) that look like a clone of something else - in some cases, that's definitely true, but in others, the creator has found a particular niche that makes the product useful in a way that other similar products are not. Not thinking about this creates risk that your brand-new product is easily dismissed as a clone of something else.