Puja Hait

I will share first two steps that I follow. Step 1: Is this problem worth solving? 1.1 Problem definition and user segmentation * B2B product: A business customer must have a genuine painpoint that they are willing to pay for. Some problems are not big enough problems, hence not high priorirty for the business users, these are not worth pursuing. Fine tune the problems till they hit * B>B>C: The business user/stakeholder may have rightly identified a problem but may not have the best ideas in terms of what solutions can work. Validate the problem is real with user research. * B2C: Similar to B>B>C, some segment of users have a need. Identify who they are and what the real problems are. 1.2 Is the Problem TAM big enough Step 2: Why us? Why now? 2.1 Do competitive studies 2.2 SWOT analysis 2.3 Are you best positioned to build this and build now?

Start with a Total addressable market (TAM) * share of TAM you can get in next 3-5 years *confidence level *Revenue per user per year * 3-5 years. In the RICE framework, you would divide TAM * Share of TAM (influence) * Confience/ Effort to then help prioritize. (Desc) Calculating Share of TAM you can get in next 3-5 years is a art more than science. Do a SWOT analysis for yourself, incumbents in the market, if any and emerging players. Also keep in mind that market/users may not always be ready to adopt. So factor in the barrier to adoption/switching costs. Confidence level is based on your ablity to execute and deliver results- ship great products, great customer support, sales channels, marketing (even if lo-budget). Do you have the right team to get this done? Is the technology there yet? Are there high risk dependencies?

I would say there is no substitute to real user data. User research is table-stakes. But in my experience, not always representative of "actual" usage, so don't overindex on specifics. Rather validate if the problem statement is indeed important for the user segments. Because if it is, then they might be more patient with your iterations towards solving their needs. Else they are very likely to abandon very early on and never return. A good way to test is whether they are willing to pay for the solution. Paper mocks UXR is helpful once you have narrowed themes and want to develop MVP scope. Then go build MVP and ship to a small user segment to learn and iterate. This step is the journey. Scale up only when you see hockey sticks for atleast one feature. Also retention loops should be naturally showing up by then.

1. Not validating the problem statement enough. Is this really a problem? 2. For a B2B product, I think its important to think through early on whether this is a problem they are willing to pay for. Often times, this is an after thought and expensive to pivot. 3. Giving up too soon. Its easier said than done to validate the problem statement. Sometimes this take iterations where you get live feedback from real users. So you might be dancing around the problem space for a bit and that's okay. 

I recommend thinking about these questions: 1) Is this worth solving? * What is the problem statement? Who are the users? * Is this a real problem? * What is the TAM? What can we influence? * What is the definition of success 2) Why us? Why now? * Are you the right team/org/company to solve this problem? * Should you work on it now? What happens if you do not? 3) How Might We break up the problem? What sub-problems should we go after(repeat steps 1-2) ?

I would consider the following factors: * What are the goals at that time? How best are the goals served? e.g need a product-2 to monetize and sustain product-1, which is growing but no line of sight to monetization * Competitive value - What is the best way to build or defend moat? Is the sum going to be greater than parts? Vertical or horizontal integration? Solution offering rather than piecemeal feature offering? * Execution confidence- Are we in the position to take on a second product? Can we deliver, maintain and do justice to both?

It depends on the lifecycle of the product and goals. 1. 0>1 product: Goal - to find product-market fit. Here its very important to think through your hypotheses, possible outcomes (Prove, Disprove, insufficient signals) and what you would do next - next set of features, V2 of the MVP and so on. Charting this out helps you then answer what you must absolutely answer to get to the next step. Once your product enables you to achieve testing of your hypothesis, ship it! This assumes that product/solution is usable and stable (not overtly buggy etc). Also in general, start with a smaller userbase, tweak and polish before going full bright. * Consumer 0>1: IMO, consumers have high expectations and they WILL compare your product with way more mature products. So its more important to pay attention to usability and product excellence (latency, bugginess, low connectivity coverage etc.) for consumer products. Its easier though to experiment relative to consumer products. * Enterprise 0>1: Here offline/hacky support solutions can work initially to help you support operationally without building all the bells and whistles. So focus even more heavily on what problems are worth solving and are the solution ideas resonating. Remember though that for B>B>C, the enterprise might think the solution works, but their users may not think the same. So user research is still no substitute to actual launch data. 2. 1> 100 product. Goal- growth in engagement userbase, retention, monetization etc. I think its good enough to ship when the solution fixes a known issue or gap even incrementally. Iterate depending on the effort vs impact equation. This fix could help retain some existing users, so it still matters. If its a novel feature, then follow the 0>1 principles in #1.#1.

Great question! MY RESPONSE TO "AT WHAT POINT IS A SOLUTION READY TO BE SHIPPED?" APPLIES HERE. The aspect of launching a true MVP is harder in a large organization, when the expectations from the customers are high and I think rightly so as the stakes are maybe much higher. In my experience, what helps calm the nerves is to play out the outcomes with the team: * What is the worst case scenario? * Asking why is this not acceptable and thinking through ROI, opportunity or sunk cost on doing more, waiting further out, could help build a case. * Experiementation path and mitigation plan 

In my experience, real human interactions help in building relationships and trust. There may be other effective ways of achieving this too. Once you establish those, working remotely does not adversely impact delivering best products. In fact, I have seen hyper productivity working remotely in some instances.