back to blog

Product Mindset #2: Minimum Viable Everything (MVEverything)

Read Time 3 mins | Written by: Kim Sullivan

Product Mindset #2: Minimum Viable Everything (MVEverything)

Document overload.

Meeting overload.

Artifact overload.

Everyone spends time in overload land. Sometimes a leader asks for multiple variations of the same thing. Or an overly process-oriented PM requires repetitive tasks. And very often, an overloaded state simply sneaks up on you and your team.

Before you know it, you are drowning and churning without moving your goals forward.

Prioritization is a natural first step in this chaotic state. But even with ruthless prioritization, it’s still easy to overkill your top priority with too much detail, process, or workflow.

Everything you spend your time on should be distilled down to the smallest piece possible while still meeting your objective. 

I call this Minimum Viable Everything (MVEverything).

To achieve MVEverything in your day-to-day, keep this list in your mind:

  • Confirm the priority: Have you gone through proper due diligence to ensure where you are about to spend your time is in fact the right place to start?
  • Distill your primary objective: What is the heart of what you are trying to accomplish?
  • Identify the minimum set of work: What is the simplest way to meet this objective?
  • Stay laser-focused: Are you drifting from or expanding this minimum set of work?
  • Confirm its importance continuously: Have priorities shifted since you started this work? 

This MVEverything mindset applies to processes, methods, artifacts, documentation, meetings, products, acceptance criteria, and everywhere else you spend your time. 

By doing the absolute minimum amount of work, on the top-prioritized things that add value, you save time, energy, resources, and avoid waste.

But more importantly, you save your sanity, and still accomplish your goals.

Examples of MVEverything

Check out these examples to save time and accomplish your goals with less waste:

MVeverything example

“Get Shit Done” (GSD) approach + MVEverything

When you practice MVEverything, you …

  • Operate as quickly as possible with urgency and focus on your primary objective.
  • Adopt the lightest possible “Everything” (e.g. processes, artifacts, feature set, meeting structure, etc.).

These are also key elements of the Get Shit Done (GSD) approach.

If you haven’t heard of GSD or need a refresher, this anti-framework of sorts helps you get from point A to B using an MVEverything mindset while also embodying the following additional aspects:

  • Do whatever it takes, whether they’re mundane or challenging tasks.
  • Ask as many questions as you need to understand all the context – which often takes you out of your comfort zone.
  • Learn and research because, yes, you don’t know everything.
  • Do all of the above and maintain excellence in what and how you deliver.

GSD and MVEverything work well together. 

Both are helpful mindsets because if one thing is certain in software development, it’s that software requirements will change.

Fast flexibility with direction changes = less waste 

To avoid waste and really stick to MVEverything in product delivery, flexibility, and speed are non-negotiable. 

Continually ask yourself:

  • Have priorities shifted since you and your team started this work?
  • Are you drifting from or expanding the minimum set of work, intentionally or unintentionally?

At some point, your requirements will change. 

Direction changes always happen during software projects – reducing waste is about knowing when to change, how to respond quickly, and how to update your MVEverything.

Consider the following when handling direction and scope changes:

  • Thoughtfully review all the information being presented and make sure the priorities won’t shift again before you switch gears. This minimizes the number of shifts in the given project duration.
  • Ask yourself and the team, when is the right time to pivot? For example, does it make sense to finish the current work under the current definition or perhaps a reduced definition? Should you stop it immediately? Does this shift warrant a change in process, e.g. stop the current sprint this Friday instead of next Friday?
  • Be mindful to minimize absorption of colleagues’ franticness, and instead, crisply and calmly communicate changes to the team. Stick to the facts — state the “why” of the direction change with all the appropriate context. The majority of the time these pivots are understandable and logical.

Work with the team on the best path forward given the new information to figure out what works best for everyone — the team, the stakeholders, and your end users.

Update for MVEverything across the board and keep going.

Follow Kim on LinkedIn

Kim uses LinkedIn to share her thoughts on product delivery, prioritization techniques, and enterprise product development and design. 

Follow and engage with her here

Don't Miss
Another Update

Subscribe to be notified when
new content is published
Kim Sullivan

Kim Sullivan is the Head of Product & Design at Codingscape.