AMA: Atlassian Director of Product Management (Confluence), Paresh Vakhariya on Building 0-1 Products

I am a fan of this viewpoint too. Here are some ways you can implement this internally, even in a large organization. Here are some ways I have gone about implementing these: * We have developed a culture of experimentation. This helps us test ideas (small or large) quickly and easily. The idea is not to be perfect, but to test them early on and see if there is impact on core metrics. * Set clear success metrics and OKR's; this will allow you to show progress towards the larger goal via small steps, making the journey measurable and impactful. * Ongoing customer feedback and usability testing to measure early impact will help you sell the long term vision * Develop a vision, but break it into phases. A phased approach helps you slowly guide your initiatives to the broader vision without building the whole thing upfront. * Having Beta releases help test ideas in the market directly without having to wait for all features to be ready. This approach provides real-world insights without the prerequisite of every feature being fully developed, thereby facilitating a feedback loop that informs and improves subsequent iterations.

Here are some considerations for continuing to pursue a 0-1 product even when you have a potential large competitor: * A niche focus that you feel is a significant differentiation that you can capitalize on. Even better if this community is easily engaged with you or you are easily able to tap into it * Early mover advantage: if you believe, being early in this market helps you penetrate the market better and users will remember the brand even when there is a recognized large player moving in * Unique idea: something that you feel is hard to replicate, even for a large competitor. It might be UX, a specific feature which you are able to patent etc. * A strong partnership with a large entity that is willing to distribute your product to the market. This ensures you have the user acquisition aspect sorted out early on * You are able to patent the technology so that it cannot be duplicated easily * You can iterate and move fast on the product as compared to a large organization which will move slowly * If you believe that your startup/product would be acquired by this large competitor anyway. (acquisition target) These are some considerations but this is not an easy decision to make without understanding the product, users, feature set and core differentiation.

I am a strong believer in a user-centered approach and that can be the foundation for any brainstorming. Some ways you can implement this too (in an organization of any size): 1. Understanding Customer/User problems: A good understanding of the problem via customer interviews, Support ticket/feature requests and other feedback 2. Quantifying user problems: A good understanding of metrics and how users are using the feature 3. Cross-functional team: having a diverse team of PM, Design, Engineering and other roles are needed would help make the brainstorming more meaningful and well rounded in terms of outcomes that can be implemented. 4. Early prototyping: we often miss this crucial step of building a prototype to test the ideas ourselves and with end customers and users. Maybe there are also some key stakeholders who can offer feedback. 5. Assessing engineering effort: Evaluating the feasibility and effort involved in building the solution helps avoid costly rework later on. 6. Usability Testing: Test the prototypes with real users to gather feedback from end users as well.

This is a fairly complex decision and depends upon various factors such as: competitive landscape, organizational vision/strategy, development effort, rollout strategy and most importantly end customer needs. 1. Customer Feedback: There is ongoing feedback from customers that point to a need for an adjacent product. e.g. Jira is for project management use cases but there is an indication from customers to bring in a wiki/documentation tool such as Confluence. 2. Competitive landscape: if the competition is indicating or building adjacent products, it might be a good idea to consider areas they are looking into 3. Organization vision/strategy: important to understand if a totally new product would make most sense or just a feature on top of existing product. 4. Engineering and other costs: Does the company have the resources to build 2 separate products and maintain them over the long run? 5. Marketing and launch strategy: Does the company intend to market 2 separate products to the customer base? Some ways to test this out: 1. Build a quick MVP and test it with the customers as a free offering. This will provide valuable learnings. 2. Offer this as a feature on existing product: See if users like the overall idea of this by offering it as a feature rather than investing in splitting the products upfront 3. Financial analysis to see if the 2 products would be successful at the same time 4. Market reception of 2 products needs to be evaluated as well. They might end up cannibalizing each other. This is a decision with many variables and needs to be evaluated alongside all of the above points.

Here are some steps I would consider: * Customer and end user issues: conduct early stage interviews to understand the end user personas, their goals, pain points and unmet needs * Define the market size and ensure there is a large enough need for the product. Some financial modeling is needed to ensure the product will be viable. * Define success measures: What would it take for the product to be successful? What are the top metrics you will go after? * Build out a MVP: if possible, build a MVP product and launch it to some key customers for early feedback. Iterate as much as you can quickly. * Test the core hypothesis: work with some close customers and end users to test out the hypothesis and metrics you are going after. Talk to them often and make quick iterations. * Develop a prioritized roadmap of future iterations: what are the missing features you want to consider building quickly? * Iterate or pivot?: continue to refine ideas but know when to pivot your idea/solution to continue to solve the core user problem.

Here are some high level issues that come to mind: 1. No market or end user need: many startups try to build a tech that is in search of a problem. Like Steve jobs said, find a real user issue and build tech that solves it. Validating this need is important. 2. The user need is just not large enough: the market has to be substantial for it to gain traction. 3. Not iterating fast enough: if feature set is not gaining traction, key is to iterate on it quickly and pivot as many times as needed. Continuing to refine a solution that does not fit user needs is futile 4. Ignoring the competition: always keep an eye out on new features and see if you can learn from it 5. Not prioritizing ruthlessly: limited resources mean that the feature set needs to be very carefully sequenced. Spending time/effort on something that does not add value severely impacts the success of the product. 6. Carefully planning the product launch: failing to target the right users with the right message means the adoption is going to be poor. 7. Not Iterating on the pricing/packaging model: sticking to a pricing/packaging model that is not working means the product will struggle in the market even though it may have the right feature set.

Projecting revenue for a product that hasn't been shipped is a tough but essential exercise for any organization. Some key inputs are: * Market size and potential addressable market: important to clearly understand and define the target users/customers and overall market size you are going after. * Competitor size and metrics: how large are the competitors? What core metrics are they going after? * Product pricing model: What is the pricing strategy your product would go after? Freemium, subscription, ads etc.? How does this align with the business model of the product? * Sales strategy: Plan for customer acquisition and costs involved * Engineering and other cost (Support etc.): estimate the cost of building a MVP product that you can iterate quickly on * Core Metrics: measuring the success of the product via a set of core metrics Based on the above points, consider building our various scenarios while considering the headwinds your product might face. Think many spreadsheets to navigate this challenging problem!