0 -1 product development refers to building a new product or service line from scratch (0) to bringing its first iteration into the hands of customers and users (1) The first step to develop a 0-1 product is to deeply understand the market need. I look at this from the buyer perspective, the end user perspective, and the competitive landscape perspective. Unless you understand, what's needed, what exists, what's missing, and what will differentiate your solution and validate your need to exist, you cannot begin the next phase, which is product definition. 

Design a product for drivers driving in rush hour. I am betting every human stuck in traffic has once thought... “Dang this traffic sucks, I wish I could [insert idea].” The best answer I’ve heard is a tablet-sized visual, that is connected to the internet with key apps such as email, song playlist, podcasts, call functionality; along with the capability for partial self-driving in traffic. Once in rush-hour it kicks in, frees your attention to do other things, improves health of the driver by reducing both physical and psychological strain of commuting in rush hours and is highly scalable to autonomous-capable vehicles. I liked the answer because I’d buy this product 🤪 but also because the answer was (1) optimized for reducing real pain points (2) accounted for the future of driving (3) was a little wild, but not too out there. When I heard this answer I could tell the PM was both imaginative but grounded in solving real problems.

Customer feedback is critical to how we build, and we incorporate it at every step of the product development process. We get customer feedback from a variety of places. When building new products we proactively reach out to customers to learn about their needs and make sure we’re creating the right solutions for them. We have a User Research team that regularly speaks to customers via a variety of methods - everything from interviews and surveys to card sorting and field studies. Along our product development process, we have specific touchpoints where we make sure to utilize user research to get deep insight into the pain points our customers face, and the best solutions to help them. Our customer-facing teams, like sales and customer success, are also talking to customers constantly as part of their daily jobs. These teams rigorously record all of the feedback they hear and compile it into a ranked Voice of the Customer (VOC) list, all managed within Asana. Asana’s VOC program is a critical input into our roadmap process, and helps us prioritize the most pressing needs brought up by customers.

A super common question! Traditionally the term "product manager" can often mean different things depending on the size of the company, the product's stage, and sometimes the overall market segment. I often times bucket them into these core groups: 1. Technical Product Managers (TPM): These PMs work closely with engineering teams on more technical products, thinks like API driven products where the end "customer" is technical in nature. For these roles, you will need a deeper level of technical expertise and the ability to understand the technical aspects of your customers needs. 2. B2C (Business to Consumer) Product Managers: In a consumer-facing environment—like mobile apps, e-commerce platforms, media consumption products — I find that PMs often emphasize UX and product design (along with core PM responsibilities). One of the key areas that this group focuses on is leveraging a typically broader/larger customer base to do things like A/B testing, and quick iteration on product designs to validate assumptions and feature value. 3. B2B (Business to Business) Enterprise Product Managers: These enterprise PMs focus on delivering products that solve businesses' complex problems. I spent a lot of my career here and this type of PM spends a lot of time on sales enablement, strategic account engagement, and roadmap management. Given that most B2B solutions have a longer sales cycle, their relationship with sales is key to success. Depending on the size of the organization, this type of PM also focuses a lot on the financial side of the product. 4. Infrastructure Product Managers: These PMs (sometimes internally facing only) focus on building components that other teams and products rely on, oftentimes within an organization. For them, the GTM isn't as relevant but they need to understand and balance things like scale, interoperability, and business alignment. Figuring Out Your Best Fit: 1. What are your Interests: Consider things like Do you enjoy getting into the weeds on technical discussions? Do you more get energized by user research and design? Do you geek out over analytical data and love looking at usage metrics to drive feature development? Each type of role has a different focus, so find the things that excite you. 2. Consider the Environment Do you want to reach a huge market of customers and iterate on minor feature developments and enhancements? Or do you want to work closely with larger business customers and develop a deeper understanding of their problems and how your product can evolve to meet those specific needs? No right or wrong answer, just what gets you pumped up each day. Remember, it’s about aligning your career desires, your core strengths, and the types of challenges that get you fired up to solve each day. We are problem solvers, so what types of problems do you love solving and how do you like solving them? Many PMs start in one area and end up in another. All the roles share a common framework of ensuring we are delivering business value for our organization and delighting our customers with innovative and useful solutions to problems they either have or don't even realize they have yet.

PM work life is a firehose of Slack/Teams message, customer emails, meeting requests and deadlines. Here is what I find helpful to make sense of the chaos and stay on top of the key things. * Capture, Organize, Get Shit Done. Resist the urge to jump on every message or email the same moment - you may find yourself exhausted while still behind on your goals. Instead, find a tool which lets you to quickly “capture” a thing which require your attention - and move on. Organize these to-dos thoughtfully - later, when you have time: what need to be done now, today, later this week? Some people find Eisenhower matrix framework helpful, though it may require much discipline and self-training to apply it to every day situations. My personal go-to solution for capturing and organizing PM to-dos is Trello. * Meetings. Look at your calendar and brutally question it. Which meetings you don’t have to be in? Which ones you’d be fine just reading a summary after? Sometimes you’ll have to say “no” to get your work done, even if it slightly annoys someone. * Async collaboration. A great way to reduce meetings load for me is Atlassian Loom: record a short video clip and share with your collaborators, let them responds or even with another video clip, async, at the time which works best for everyone! * Focus time. Every week you likely have a Big Rock - a bit of work which isn’t immediately urgent, yet have an outsize importance and require significant focus time to accomplish. * Plan your week. Apply everything above to your Friday routine - plan your next week ahead. Meetings you’ll decline? Focus time you’ll block on your calendar - to accomplish most important tasks? 3 things (maximum) you are looking to accomplish next week? * Plan your energy, not time. Lastly, recognize when you are at the peak of your productivity - late afternoon? mid-day? morning? Do your best to allocate this time to the most important things you are looking to accomplish. You are most productive on Fridays? Make it a no-meeting day to finish up that blog or product spec!

Honestly, the first product manager for a company is probably not ready to establish a prioritization framework. The first PM probably needs to focus on customer discovery, market discovery, MVP intuition, and experimentation. Until you have established product-market fit with enthusiastic customer demand, rigorous prioritization is probably bikeshedding. Once you have that fit, that's when you'll start to get inbound requests/ideas/complaints from current customers, potential customers, new market segments you hadn't considered, and sales teams eager to displace competition. Then you can start thinking about a model to trade off product vision, addressable market expansion, competitive threats, technical debt, quality & reliability, scaling bottlenecks, and so on. The question you'll ask is: What can the team work on today that maximizes short term opportunity without hobbling long term viability? Product priorities more often resemble a Bayesian decision network than a flow chart.

I'm going to suggest a few processes, but please do scale each process to the size of the organization. Treat your processes like you treat your product - establish 2-3 internal customer problems that are actually worth solving, and solve them with an MVP of a process and iterate as you learn - don't try to introduce everything at once. * Quarterly priorities: Getting into the habit early of writing down the plan for the quarter is a good muscle to build early in establishing the PM discipline even with only a handful of PMs. Focus on articulating the big bets for that quarter and the value delivered, written in language that peers and leaders can understand. A key aspect of this is establishing OKRs each quarter to ensure alignment across the team, and cross functionally to drive product and business success. Incidentally WorkBoard is an awesome tool to enable this * Specs: Writing things down avoids late churn. It allows articulating the why and the what for a feature. Engineering can start work in parallel with some details getting ironed out (not a waterfall process), but the why and success metrics should be clear up front * Design / Experience walkthroughs: Notice I'm not calling these reviews. Reviews indicate a level of red-tape that is not necessary on smaller teams, but it's still critical to get feedback early from stakeholders, leaders and customers, so start doing design walkthroughs earlier rather than later, and you can avoid major churn later in the product development cycle Team meeting: Reserve some time each week (PM only or PM+Design depending on team size) to look at the tactical work happening, what's coming up, concerns/help needed as well as to celebrate small and large achievements. As PMs we often forget to celebrate the good, so make space for this.

If you know that customers are not willing to adopt your solution, that's a bad spot to be in. 1. Re-evaluate what led you to the decision to build & when to do it. Was there a gap in your methodology, or a piece of research that led you down this path? How can you avoid this for the next piece of strategy planning? 2. Don't hope for better adoption -- test and prove this out. Can you get a high quality signal that customers will adopt, e.g. customers will pay you now for access to it? 3. Is there a wider org that will bear the cost of holding this solution, and values it for reasons other than direct revenue?

You should think of it as: it should be ready to be shipped when it's the first shittiest version, and when it's the best version of itself. The question should not be not so much about readiness of the solution, but readiness for whom? I've witnessed teams who got too excited when creating a new product and opening the floodgates to let anyone try it too early. That usually doesn't end well... You don't want many people jumping on the solution when it's not ready for them: first impressions won't be good, they won’t stick around and you'll need to work hard to get them to try again. Here's the approach we take in my teams: basically, for anything we ship, whether that's big new features to Jira Product Discovery or new products (including Jira Product Discovery itself), we work with progressively more customers (10-100-1000) before making it generally available. It helps us test the solution very early with a handful of customers to get feedback and make sure the solution delivers on its promise for them, and ensures that everyone only gets the solution when it's ready for them - thereby increasing retention & minimizing churn. If you want to learn more you can watch this talk I gave about the process we went through when creating Jira Product Discovery. You can also read more about this topic in the Atlassian Product Discovery handbook, that we wrote to help with things like this. 0->10 customers (preview) In the first phase of early stage bets we only work with max 10 customers. We unpack the problem and test solutions and iterate fast, which is a process that’s best done with a small number of users/customers that feel the problem the most. And we get the solution right for them. It’s easier and much more focused to do it this way than “throw it out there and see what sticks”. Users who feel the pain the most will be happy to work with us, we can chat with them on Slack/Zoom/Email easily. They're happy to work with incomplete solutions (we can take a LOT of shortcuts) and we can remove the need to pile on untested assumptions. If the solution doesn't work we can throw it away, it's cheap, no harm done. To demonstrate progress to leadership we use metrics that best represent what we're trying to prove at each phase. We started with the following for the private preview of Jira Product Discovery: 10 active teams have been using the product for more than 3 months and plan to continue using it when we enter beta 10->100 customers (alpha) Then we progressively invite more customers to use the solution. At this stage we usually need to polish rough edges and address more scenarios based on what we learn from working with customers of varying needs, and maybe less willing to work with a rough prototype. It's also harder to collaborate with every customer 1-on-1 so we need to create better onboarding material, demo videos, etc. We move support to a community forum. Our success metric at that stage when creating Jira Product Discovery was still focused on problem-solution fit, but for more customers: Product market fit score of 40% or greater with 100 active teams (I highly recommend the Product market fit score survey, and you can read all about it here) 100->1000 customers (beta) At some point we become ready to share with more users, in our case for Jira Product Discovery it was when we reached 50% PMF score for more than 100 active teams. At that stage we needed to focus on making the solution fully self-service - we couldn't afford to have to talk to every customer once in their journey. So we focused on in-app onboarding, we improved usability, we polished the design, we scaled the technical implementation, we trained support and sales teams, etc. It's really about making it ready for prime time. It was also time to change how we measure success by introducing more metrics that represent the health of the funnel as more customers discover, try and adopt the solution on their own. That’s when we started adopting pirate metrics (AARRR), and here's a great read about them. In the early days of that stage we also focused on validating a pricing model, but that would be a topic for another post. Once we were done with all that, had high PMF score for 1000 customers, healthy conversion rates and retention, low churn, validated pricing - that's when we decided to make Jira Product Discovery generally available. These phases work for us - it doesn't mean they will work for you, but I believe that this general approach should apply to a lot of contexts. Basically: don't focus on "when the solution is ready to be shipped?" but "who should we be working with right now based on the state of readiness and validation of the solution?"

* The right PM to Eng ratio depends on a couple of different factors, many of which can from my perspective be boiled down to 1) the overall stage and scale of the company and 2) the nature of the product you are working on. Given those dependencies, it also makes sense to revisit this decision at key turning points of your product (or company). * Practically speaking, the traditional ‘2 pizza box team’ of 8-10 engineers per PM is a decent baseline to start with. Here are a few example considerations of how I would think about adjusting this ratio for individual teams based on scale and product considerations: Scale * Larger scale for an R&D organization usually implies an increased need for coordination and likely more ‘interfaces’ (e.g., there are more product and engineering teams, more platform-wide services, APIs etc.) and in many cases this maturity also brings technical complexity. All of these factors might indicate that a single PM can cover a wider range of engineers, so even a ratio of 1:15 might work in those cases. This doesn’t necessarily mean that a single engineering team needs to hit that size, but PMs might start work that naturally spans multiple (potentially cross-functional) engineering teams * Smaller companies can usually start out with an 8-10 engineer per PM ratio and then adjust based on growth trajectory. In hyper-growth scenarios, PM capacity can become a bottleneck, especially when it comes to B2B/Enterprise-oriented products, where in-depth knowledge and a clear articulation of specific customer processes and varying user personas might increase the need for more dedicated PM bandwidth (and critical product trade-offs), adjusting the ratio to 1:6 could temporarily make sense Nature of the Product * A product or feature with high user complexity (e.g., enterprise operations workflows with varying business needs, complex business logic) or high initial business uncertainty (e.g., first foray into a new market) might warrant more PM bandwidth and an adjusted PM to Eng ratio of 5-6 engineers per PM * On the opposite end of the spectrum, lower user complexity (or generally higher Eng complexity) would lead me to move towards a ratio that skews towards more engineers per PM (typical examples here could be AI/ML-driven features that might require a wider range of technical expertise and teams to succeed)