Why You Should Fold On Status Quo Software Lifecycles And Bet On Quick Wins

Software-Lifecycle-Explanation

Alpha, beta, prototype, MVP, MVE, pilot – what these mean to any given business is anyone’s guess, including the teams building them. Having disconnects among business leaders?  Me too, but there are more outcome-oriented approaches to product management (like Headstorm’s Foundry), and I want to tell you all about how they can transform your software lifecycle. But first, I want to talk about a psychological phenomenon in poker.

It’s called being pot-committed: it happens when you’ve invested so many of your chips into one hand, that to fold your cards on the very last round of betting seems inconceivable from an ROI standpoint. It might look a bit like this:

software development lifecycle (SDLC) pot committed opponent and you example Why You Should Fold On Status Quo Software Lifecycles And Bet On Quick Wins

What’s so strange about this condition is that in many scenarios, even pro poker players will mistakenly believe they’ve reached this point of commitment – even when the data and context tell them it’s not true. It happens because they’ve worked so hard to reach this point, and the weight of prior effort clouds their ability to make the smart move.

In short, the players are using their inputs as an excuse to justify a lack of control over the outcome. Effort, as a safety play.

But just like poker, your market won’t hand out an A for effort. It’s the outcome that matters.

The language barrier between engineering and business teams is what allows misguided efforts to fester. How many times have you seen alpha or beta releases die on the vine, or go over schedule by 200 – 300%? Often, those hang-ups will rest on one or two major features – and the question to ask yourself is, why are you committing so hard to features that haven’t been market-validated?

Effectively, the mindset in need of a shift here is what you’re committing to. Instead of committing to reach the natural conclusion of your prior efforts, you should be committing to valuable outcomes you can demonstrate. One remarkably easy way to make that shift is to break down the language barrier between engineers, business teams, and customers. It’s a key facet of Foundry’s high-communication, high-maneuverability strategy to iterate faster and win more decisively. So, let’s talk a bit about how we achieve it in regards to releasing products in the software lifecycle.

Hold Your Teams Accountable To Value, Not Effort

Product leaders who package a set of features into a release – be it alpha, beta, MVP, pilot, etc. — are unwittingly telling engineers, “your goal is to make this effort.” That’s where the disconnect starts.

Our Foundry process eschews traditional software lifecycle releases for precisely this reason. Instead, we communicate across all teams the value that we’re seeking in a release — and we do this in large part to empower anyone on the project to say, “we need to rethink this feature to make deadline” or “maybe this can be solved quicker with design rather than code” or “we could get the data we want here with half the effort if we had a customer onboarding experience.” It’s the kind of indoctrination to aligned outcomes that great teams thrive on, regardless of how they delineate their software lifecycle.

So, let’s lay out the framework that CXOs, Heads of Sales, and of course product and engineering leaders co-designed with us to distill a common outcomes-based language (shout out to our amazing clients at Headstorm).

SDLC comparison of business as usual to value focus Why You Should Fold On Status Quo Software Lifecycles And Bet On Quick Wins

Quick Wins: table stakes features for a demonstrable value proposition in a market. This is where the need and the idea from planning phases turns into the solutions and features that attract customer attention, spark an investor mindset, and promote early but viral sharing amongst colleagues. Quick Wins can happen through all manner of user experience (not just experiences with UI layers), which is why it’s imperative that the entire delivery team stays aligned on building towards outcomes rather than a burndown of sprint tickets. If you’ve deployed an alpha (or MVP, or MVE, or pilot) release that can’t speak to quick wins, you’ve got no business case to build the next release… and you’re likely lacking a social contract for Sales & Marketing to help build momentum and create investment.

Flagship Features: building out the experience and its components that will turn your users into raving fans & amplifiers, in support of both buyers and fellow users. The great chasm to cross here is in developing not for what was on the original roadmap, or what an executive wants to see, but instead developing for the facets of your product that win skeptics and skewer status quo objections. Tesla famously built a handful of distinguishing product features that eventually propelled it to the world’s most valuable car company. Nobody cared that such features were in “beta” — the early adopters wanted to share and teach their new experience to others. It was enough validation to move Tesla into the next step, which is all that mattered.

Strategic Bets: fueled by buyer and user feedback and market trends; the stage where differentiation is cemented. If delivered correctly, the strategic bets you build become the hurdles that force organizational reinvention from the competitive landscape if they want to follow. It’s the point when you’ve solidified your presence with market share and mindshare.  To sanity check this phase and its features, Headstorm uses a 5-point scale and only accepts 4s or 5s to help demonstrate the value:

Our software lifecycle rating system

So what’s next?

Forging your way successfully through all the above eventually leads to scale – where revenue streams are matured and every new audience can be projected & assessed for ROI. So, what then? Ride off into the sunset? No – great product teams continuously optimize.

Optimization is indeed a growth process, but not always growth as defined by the product team. Sure, you can optimize for improved features or faster performance, but you can also use this phase to make crucial decisions about your product’s role in your broader portfolio.

Perhaps one feature outshines all others, to the point that it deserves its own spin-off product and a reassessment of what it leaves behind. Or perhaps the market abruptly shifts and leaves you overleveraged in your product. Here again, remember what you choose to be committed to, and always be aware of it: you don’t exist to keep your products alive just because you’ve worked so hard to get them here. Know when to fold ‘em, as they say.

Headstorm applies the Foundry discipline to nearly all our client projects. It’s part of the secret sauce that yields 87% faster releases and 95% efficiency gains, just to name a few.

We teach innovative companies to turn quick wins into a portfolio of well-developed products, value-tested for impact on a level that every team member can appreciate and communicate… whether they wrote the code, the creative, or the business plan.

Visit our Foundry overview to learn more, or get in touch to start asking the right questions about your software lifecycle.

◅ SEE OUR SERVICES

Learn how our suite of capabilities fuels business innovation

GET IN TOUCH ▻

Talk to us about solving data-driven challenges with speed & scale

Cookies Content

This website uses cookies to ensure you get the best experience on our website. By continuing to use our site, you agree to the use of cookies. Read more about our privacy policy.