After launch: turning an MVP into version two

Start by checking whether people can complete the intended task reliably. A broken confirmation, confusing permission error or failed upload can distort every other observation. Fix defects that prevent the experiment from working before interpreting low usage as a lack of demand.

Keep support issues, usability problems and feature requests distinct. They can all matter, but they require different decisions. A request for an export may indicate a missing feature, or it may reveal that users do not trust the information already shown on screen. Investigate the underlying need.

Use analytics to find where people stop, then talk to representative users about what happened. A drop-off chart shows a pattern; it does not explain the reason. Someone may leave because the price is wrong, the next step is unclear or they have already found what they need.

Compare cohorts and acquisition sources where the sample is large enough to support it. Avoid treating a handful of enthusiastic early adopters as proof of a broad market. Preserve useful qualitative observations, but label them as observations rather than universal facts.

A first release may be constrained by discovery, activation, reliability or repeat use. Choose the most important current constraint and state how the next change should improve it. Adding more features is unlikely to help if prospective customers cannot understand the existing offer.

For each candidate, record expected benefit, evidence, effort, dependencies and risk. Keep the comparison simple enough to revisit. A small improvement to the core journey can be more valuable than a large addition that serves an untested audience.

Keep releases small enough that you can identify their effect. Define the measure before deployment, check the important journeys afterwards and retain a recovery path. If you change several major parts at once, it becomes harder to explain either improvement or regression.

Review the original assumptions as the product matures. Some temporary manual work should now become dependable automation; other parts may remain manual because demand is still limited. Version two is an opportunity to strengthen what users value, not an obligation to build everything postponed during the MVP.