The core concept of the Minimum Viable Product (MVP) is to pilot a quick, low-investment proof-of-concept product to validate the behavior/needs/functionality with the end users. The work is intended to be iterative and potentially thrown away at the end of the evaluation cycle. The MVP is intended for ‘new’ processes or products
The best MVPs start with the mindset of
I know enough to create an initial design, but I don’t know enough to invest resources into the final product. I need to learn
Why We Need Processes: (Human)
Product development requires processes to ensure quality and consistency. Not all products require the same set of processes or rigor within a process. Misalignment of the required processes or rigor can result in low-quality products (missing processes, rigor too low) or wasted engineering effort (unneeded processes, rigor too high).
Both types of misalignment led to discontent among the developers. They can see problems even when they don’t understand the root cause.
Why People Follow Processes
People will follow processes if 4 conditions hold
- The process does not significantly slow down their ‘core’ work
- They see a near-term impact of following the process
- There is consistent support from management for the process
- The sum total of process work is seen as low.
The final point, ‘seen as low,’ is critical. If new processes are added too quickly, then the total volume of process work is seen as high. By having a ramp-up to processes, they become part of the background work and can be mastered before new processes are introduced.
One Size does not fit all
The pitfall of people working in a process/systems engineering role is the belief that what worked before will work now. (This is a pitfall in every field.) In many, if not most, cases, this will be true, but care still needs to be taken in ‘assigning’ processes. Which brings us to the thesis of this post.
Processes are “New”: The case for MVP Processes Adoption
Thinking about the objectives of an MVP and the resistance to Processes, it becomes clear that, with modifications, Process Adoption should be treated as an MVP
- Incremental rollout:
- New processes are tested out at a small scale to determine if they fit the needs.
- Users of the process give feedback, validating the process and giving them buy-in
- Prevents “process dump” burnout
- Validation loop:
- Bugs and issues in the process are discovered early, reducing re-work costs
- Low-cost:
- Developing, deploying, and documenting a process takes resources; by identifying issues early, sunk costs can be reduced
End Note: Why We Need Processes: (Legal)
There is a second reason we need processes: legal liability. In the case of an issue with the product, showing that the company developed it following industry best practices insulates them from repercussions. This is the truth, but this will never be what motivates developers to adopt processes. When we emphasize this as the reason to adopt, we get reluctant adoption.