Zum Hauptinhalt wechseln

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice

Don’t settle for the minimum viable product: Three ways to build a robust product release

Baruch Sachs,
Teilen Share via x Über LinkedIn teilen Kopieren ...
Blog abonnieren? Einfach anmelden ...

When it comes to building a solution that can tackle tough problems, the quickest method to deploy the solution to users is usually referred to as a minimum viable product, (MVP). After deploying an MVP, standard guidance is to think about a minimum marketable product, then a minimum marketable release, and then (every time you release a feature) a minimum marketable feature. The list can go on and on which can become confusing and tedious.

Even organizations that are user-centric and employ a design structure that puts the customer at the center of the process end up conveying to the customer that they only care enough to provide something that is minimally viable and nothing more. And as a consumer myself, why would I want to do business with an organization that is content to allow my first impression to be guided by something that isn’t fully what I want or need? What if businesses could have the mindset and ability to focus on what the consumer wants in the first place?

At Pega, we’re focused on providing what we call a minimum lovable product (MLP). In addition to being user-centric, MLP can be the first step to delivering successful and repeatable business outcomes. After the MLP is developed and deployed, organizations can collect feedback, iterate on that feedback, and keep delivering until the overall objective is met.

This seems like a simple and straightforward concept yet many teams, having done the hard work to create and deploy an MLP, find themselves at a crossroads of indecision for what to do after the objective is met, especially if the feedback they received is overwhelmingly positive. Seems weird, right? However, getting positive feedback causes a bit of a quandary for teams as they want to capitalize on that initial success and ensure they can keep delivering outstanding MLPs. In short, the indecision about what to do next after your first MLP is brought about by lack of clarity of what the MLP represents.

How to develop a strong MLP

An MLP is the first iteration to fulfilling the dreams of your customers or organization. Ironically, a successful MLP might mean that you never – yes never – complete the customer’s full dream due to changing business plans and goals. While that may sound odd, successful companies and brands (such as AirBnb and Dropbox) never actually shipped the full product they initially envisioned. Instead, they adopted a rigorous and conscious effort to think through the minimum set of features required to get the maximum amount of feedback from users. That feedback was then used to drive where the products went and how and when new iterations were deployed.

Here are three key considerations for prioritizing what to include in an MLP release:

  1. Technical feasibility. You need to choose an achievable MLP. For example, avoid creating an MLP that requires unreleased integrations. Your technical team can advise you on which microjourneys have functional dependencies and which can begin immediately.
  2. High business value. Select an MLP that delivers high value and progresses towards meeting the organization's strategic business outcomes.
  3. Timeframe. Prioritize MLPs that are deliverable in 60-90 days. Smaller MLP releases improve the chances that you succeed at Go-Live. Smaller, more frequent releases show value, and you can gather feedback to improve further iterations.

Once you have the microjourneys set, you can build the process once, go live, then deploy that same process over multiple channels and personas. And you can choose to deliver one or more microjourney at one time.

It’s important to remain curious throughout the process by asking yourself, “Why are we doing this?” and “What value are we delivering?” for each feature and function in your MLP. And for subsequent MLPs, ensure that you are not delivering something that is just viable, but something that builds integrity with your users and enhances the ability to adopt your solution on a wider scale.

Continued iterations with MLPs

Now that you have defined your MLP microjourneys, it’s time to agree how the business will change once you go live. This is an important step that, when done correctly, can tie together all the MLPs that you may plan in the future. In order to do this, employ some of the user centeredness you demonstrated when deciding what the MLP would look like and turn it inward. Bring together your stakeholders to agree on how this MLP will shape the way you do business.

Pega Express™ is part of this solution to ensure that you know where to go next after designing, developing, and deploying an MLP. With Pega Express™, the best practice is to deliver one or two microjourneys per MLP and choose ones that provide you with the best mix of outcomes, high volume, and ease of implementation. Learn more about Pega Express by joining us for Pega Express month this coming January 2022.

Achieve greater results faster with Pega Express

Maximize the power of our software and jump-start your digital transformation.

Learn more

Rapid delivery. Real outcomes.

Quickly build high-quality, outcome-driven applications that evolve with the changing needs of your business.

Learn more


Thema: Digitale Transformation

Über die Verfasserin

As Head of Innovation at Pegasystems, Baruch Sachs is an experienced leader and learner in helping organizations successfully navigate and de-risk their digital transformation journey.

Weiterempfehlen Share via x Über LinkedIn teilen Kopieren ...
Weiterempfehlen Share via x Über LinkedIn teilen Kopieren ...