It’s human nature that businesses have a desire for software estimation.

For projects with a fixed scope, typical estimating methods can be off by as much as 70%. And that’s a product that doesn’t adapt to user needs.

If you desire the economic growth that comes from building winning products for customers, the numbers will be even worse.

The short of it? Don’t bother! Pick a budget for what you can afford each month, and let a qualified development team or consultancy tell you if they can build a minimum viable product (MVP) in 1/6th to 1/12th of that budget.

This will produce your core theory of value and two delighting features early, with monthly budget left over to adapt to changes.

If you find that the product needs to change spend some budget on those changes.

If you find that the product needs to improve in quality, spend some budget on beefing up testing.

Software projects don’t fail because the product couldn’t get built in time – they fail because they DON'T DELIVER VALUE high enough to justify the investment.

To reach this high level of value means spending less time envisioning, and more time ADAPTING.

The only way to do this is with a laser focus on the core theory of value, and a budget that will last through several feedback cycles.

Any time a product owner/manager or non-technical person of any sort asks for an estimate, they create anxiety in those doing the work.

Experienced technologists know the number of variables in software development is ridiculous, and systems that have been created so far to account for all possible outcomes fall far short of being helpful.

Though we may need to estimate whether we can deliver the core theory of value within a time frame short enough to get feedback, ongoing estimation should be unnecessary if budgeting of software is done on a subscription-based, value-focused basis.

Software businesses must ensure that insights about how the product is being used are recorded with every release of the product.

Minimal change must be introduced each release, to allow for A/B testing to determine whether a change had the desired impact on business outcomes.

How business outcomes are measured is specific to each business, but these must be determined and agreed upon BEFORE development of any feature that will impact them starts.

The effort of a successful software project focuses on measuring whether each release is getting the business CLOSER TO AN OUTCOME, not closer to completing a FIXED SCOPE OF WORK!

This paradox can be hard to wrap your head around, but it must be fully appreciated to operate in a truly lean fashion.

Determine what you can spend per month, get started, and adapt…

TRUST THE MARKET, not your ego!

Join my Patreon:  https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech:  https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide:  https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube. 

Related resources:

• Principles of Product Development Flow (Amazon)

Visit me at thrivingtechnologist.com