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.
I would consider the following factors:
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 recommend thinking about these questions:
1) Is this worth solving?
2) Why us? Why now?
3) How Might We break up the problem? What sub-problems should we go after(repeat steps 1-2) ?
I will share first two steps that I follow.
Step 1: Is this problem worth solving?
1.1 Problem definition and user segmentation
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?
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.
It depends on the lifecycle of the product and goals.
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.
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:
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.