BROADCASTS.com

It\u2019s 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\u2019s a product that doesn\u2019t 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\u2019t 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\u2019t fail because the product couldn\u2019t get built in time \u2013 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\u2026

TRUST THE MARKET, not your ego!

You can also\xa0watch this episode on YouTube.\xa0

Related resources:

• Principles of Product Development Flow (Amazon)
• Minimum Viable Product - Letting Software Companies Help You Profit
• Agile Project Management - Is It Stopping You From Being Agile?
• Lean Software Development - It's About Uncertainty!

\xa0

Visit me at JaymeEdwards.com

Find me on Facebook at JaymeEdwardsMedia

Find me on Twitter as @jaymeedwards