In the process of lean service planning, or in the process of building and validating services agilely, the most important part is how well you negotiate agreement on controlling variables.
The part most misunderstood when defining the spec for an MVP or a first release is "let's just build it first." A considerable number of MVPs that startups try to implement and validate, and early products (services) that secure angel funding, still lack data collection or an admin.
But the irony is that validation is not actually done, and when investment is fortunately secured, data validation that was put off is further delayed by follow-on requirements and BM expansion. Of course, the expectation is that more hiring with the investment will solve it, but it is not easy. And most of the time, this is the moment when the initial concept gets damaged.. passively pivots. The reason is that too many variables have already occurred to be validated or judged.
"Let's just build it first" is merely self-satisfaction or self-consolation for the owner or decision maker. What lean or agile organizations should be doing is not building a portfolio that says "we can do this too," but matching and managing, unit by unit, the fit with the consumer in the market.
Service planning, development spec setting — not just internal decision modeling but early market validation through user research — is fully possible at the prototyping level.
Whether CB or OB, before the product is exposed to the market, prior to "implementation," you must 1) compose the entire service scenario (the mountain), 2) declare the main hypotheses that compose that scenario (the owner, the county office of jurisdiction, forest, trees, stream, animals, passersby, accessibility, etc.), 3) set the priority and flow for each hypothesis. Set each individual hypothesis as an epic. Use unit sprints composing the epic to form individual MVPs to be validated.
From this stage, the service must be planned on a foundation of rigorous variable control, and each unit must have an environment for collecting and reviewing the OMTM metric to validate and the basic data. This part (tasks, development scope, review process) is not a problem of task difficulty or schedule adjustment. It is a very important precondition that must be set before moving forward with the work. That is, in a lean or agile organization. In organizations that are not waterfall — where requirements and evaluation criteria are already specified — this is the only metric that can represent the internal members' value judgments and the external market's stakeholders, so it cannot be postponed, and it is not something to outsource.
TMI x2
When talking about lean or agile, there are products that feel closer to big corporations than to the famous domestic and international startups that come to mind. And many new products are learning from their playbook, as in a kind of "Daechi-dong tutoring season 2." Personally, though I don't have that large a network, many places seem to follow not the product but the organizational culture.. copying tools and processes that look like the right answers, as if they were habitat. But you should not simply benchmark product changes exposed at the client level or attitudes toward work methods and organizational culture exposed in outside media. What is especially more worrying is when a member who belonged to such a famous organization joins a different-shaped and differently-conditioned organization and, as if an evangelist, propagates organizational culture and work processes — that is even more dangerous. Democracy and civic consciousness are not easy to settle through import, as any adult of working age already knows. Organizational culture is no different. Benchmarking a product and benchmarking a culture or attitude are, I think, different-dimensional matters.
I've only wandered Silicon Valley as a tourist once.. but under the sequence of quickly shipping products and briskly updating them, and under the seemingly elegant lean startup or agile process, like a swan's feet, there must have been very fierce paddling — collecting and analyzing data.
