Brandon Green

"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.

Everywhere! Users themselves, colleagues, market research, competitors, randomly in the shower. Generally, I like to consider each idea seriously and work through a few questions to help decide if they are worth building: 1. What, fundamentally is the problem this idea is meant to solve? How worth it is solving that problem vs. others I know about? Does solving this problem create opportunities or risks in any form that I should think about? 2. Is this a problem I need to solve now, in 6 months, in 2 years, etc.? What's the risk of just putting it off? 3. Has this idea been validated in some form already? What's the "why" behind this being an idea? Is there a good hypothesis around it? 4. If it hasn't been tested yet, is there a low-cost iteration of this idea that my team could build and test quickly? What (rough swag) impact or learnings could a low-cost iteration yield? This feels like a lot of questions, but I've gotten good at answering them quickly with a few driving assumptions to help keep myself moving. This is really hard early in one's product career, and potentially when you're working in a very new job or problem space - but as you ramp up, you start to be able to answer them faster.

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 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.

A PM's job is to take in a lot of inputs (including the 3 listed in this question) and articulate a compelling strategy and roadmap around achieving the best outcomes for your business. Within those are assumptions, risks, opportunities, etc. that are worth digging into and questioning, and from there you can usually start to get a sense of where to focus. To a certain extent, you'll need to at least focus a little on all of these inputs, just to get a sense of whether they're worth digging deeper on. I think the answer around "where to focus" will differ highly based on the context you find yourself in, but I think you can start by asking yourself what the biggest immediate problem or opportunity is, based on what you know. Oftentimes the inputs themselves will help provide that direction. For instance: in my current role, I have a wide scope with a lot of users to consider, stakeholders to partner with, and problems to be solved. Some of the problems that appear impactful on the surface I realized were not very actionable as is for a number of reasons, so I chose to shift focus to an area that was immediately actionable, had resourcing focused on it, and I had prior experience to help guide me on potential solutions. I was able to then demonstrate some short-term impact and hire a PM to drive value in that space, allowing me to shift over to another problem area. I also realized that one of the business goals related to that space had some assumptions built into it that we began to question as a result of the work we did, allowing us to shift the priority of that business goal a bit.

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 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'll speak to commonalities in IC PMs since I have less experience hiring other product leaders. It's really just 4 things in my view: * A clear ability to break down complex, multi-faceted problems into digestible, actionable chunks, as usually shown via some kind of case interview. * Excellent ability to ask good, tough questions * A clear track record of having an impact and/or continuous learning/improvement. This may not necessarily be demonstrated through previous work as a PM, but the candidate is able to speak clearly to the impact they distinctly had or the specificity of the learnings they captured. * Genuine interest and energy around the problems discussed in the interview cycle. This may show up in a case interview (ie. clear enthusiasm about the challenge presented) or when asking questions about the role/company. I always like to see how a candidate reacts when I answer questions about the business/product, challenges we face, etc.

I personally bias toward PMs (or aspiring PMs) with a creative mind, whether that's shown through actual background experience in a creative field, or a highly creative or unconventional response to a question asked in the interview process. I find creative types (often with liberal arts degrees) to be highly effective PMs and leaders due to a common ability to connect dots and find problems and solutions others may not see or understand. This is not a requirement for a product role, but I do think it's somewhat unique compared to what typical PM hiring managers screen for.

I think going "above and beyond" is a totally subjective thing; it is up to each individual what is above their baseline of preparation for an interview. But - here are a list of things I think are table stakes, that every PM candidate should do at a minimum to prepare: * Know the company you're interviewing with: their main products/features, how they make money, how they differentiate from competition. If you're interviewing in a division of a very large company (eg. Amazon Logistics or AWS, both parts of Amazon), understand the same thing but for that division. * Brush up on your past experience and how you speak to the impact you've had. I like to have at least 3-4 examples I can easily pull from, at the top of my memory, so I can quickly and confidently tailor a real story to a question that it makes sense to apply my example to. * Get clear on what you're looking for in the role you're interviewing for - how you think you might be impactful, what the first 3-6-12 months may look like, etc. * Get clear on what you're looking for in the interviewers - any red flags to watch out for in how they ask questions or react, what questions you'd want to ask them about the role/company/etc. I basically recommend these 4 things in every situation, at least.