Cut scope, not time or people
Momentum is created and preserved by reducing the size of commitments, not by endlessly scaling team sizes or putting pressure on the team mid-development. That only makes late projects later and will decay product quality over time. Keep deliveries small enough to be completed within one to three weeks, with a clear outcome and as few dependencies as possible. Smaller scopes force everyone to think clearly about which features to actually prioritize. Instead of thinking or talking about doing something, you decide to do it or not to do it.
Smaller scopes shorten feedback loops, expose mistaken assumptions early, and turn plans into observable progress. It makes changes easier to test, releases smaller to manage, and mistakes easier to fix.
By scoping down you will:
- Eliminate the need for release management
- Reduce the need for test teams
When work begins to stall, change the scope before adding time, people, or adjusting process. Preserve the essential outcome, remove everything that does not contribute directly to it, and deliver the smallest complete step that moves the team forward. Momentum compounds when finishing becomes a habit. Over time your team will begin to have an execution bias and prioritize delivering value above all else.
Proof of concept
The proof of concept exists to validate technical and functional assumptions, and explore novelty, at a low cost.
They should be viewed as minimal viable prototypes, where we prototype and build exactly enough to validate whether or not a concept can technologically and directionally work, before spending months working based on flawed assumptions.
Most of the steps can be and in most cases should be manual. Copying database files, generating fake data, copy pasting e-mail addresses to an external solution, are all good practices and should happen in the proof of concept phase.
This will instill fear in a lot of developers, that have been getting used to pilots becoming the de facto production solution, not getting to the next phase etc. If you have this problem, it is a cultural one, where managers have not done their job in cleaning up after pilots and tests, and the tech leads should feel empowered by having the authority to prioritize cleaning up
learn about our elegant solution to all tech debt
The code in this part should not be reusable, it can turn out to be, but it's not a goal in this phase.
What is important is to split each concept you are trying to prove into their own smaller chunks that are easily verifiable on their own. That way you don't have to say "it worked, but..". Instead you can clearly state "X and Y worked, but Z failed because of..", knowing exactly which concept was the weak one.
Minimal viable product
The key word here is product, it should be feature-poor, but not bug-rich. No admin dashboards, no perfect integrations, manual tasks are still ok, and the UI deoesn't have to be perfect.
The idea is to scope it down so hard, that it hurts to run it in production. You should still leave a lot to the next phase.
Commercially viable product
it's greatest practical value is as a scoping weapon. The CVP exists inside the project as a designated bucket to catch stakeholder and developer panic. I borrowed this term from a banking friend that used to have a lot of B2B customers in the banking space. While MVP might be ok for internal testing in such environments, the CVP needs to be scalable. This phase isn't mandatory, but I find it to be useful just to get everyone on board with the MVP. It is more of a tool for scoping down than anything. It could be a part of iteration but it's cleaner to seperate it as a step before it can be prioritized under other things.
It is a bucket to catch stakeholder and developer panic, by pushing everything that people believe you have to include into the "next phase", you will end up eliminating a lot of it.
Iteration
You test a few concepts, choose to move them into an MVP, push some things to the CVP, and the CVP should function as a combination of MVP iterations, the combination of the phases will be different. This does not mean you don't release continually. Releasing continually is important still.
The clue is to transition the feature into active continuous iteration instead of letting a "project" run indefinitely