We prioritize things everyday What to wear. What to eat. What email to answer first. Whether that 1:1 can be rescheduled without sounding rude. It’s all prioritization. So when someone say “I need a framework to prioritize,” I get it. But also… you’ve been doing it your whole life. And in product management? You do it all day. Which user group to focus on
Which feature to cut
Should we fix the bug or chase the roadmap?
Do we delay launch or ship with a known gap? Which user group to focus on Which feature to cut Should we fix the bug or chase the roadmap? Do we delay launch or ship with a known gap? Welcome to PM-ing where we’re all juggling fire! Why I built my own framework There are 100 frameworks already. RICE. MoSCoW. Value vs Effort. Whatever AARRR is. And I remember… none of them. This is because most frameworks help you start the conversation butnever help you finish it. but You bring one scorecard. Someone else brings their own. Everyone politely presents. No one agrees. Now it’s trial by combat. Great use of time. Here’s my take: Every company should have its own prioritization framework.  Yes, bold. But hear me out. If you’re optimizing for your values — speed? quality? retention? learning? — then your prioritization should reflect that. Not some generic score from a textbook. its own your So I made my own. This is the framework I use right now and I’ll use in my future company (fingers and toescrossed for this one).And I called it: VITALS. and toes And I called it: VITALS. VITALS The goal: Prioritize for a Minimal Lovable Product Not MVP. MLP. The thing people want, not just tolerate. want It should feel possible to build. Easy enough to adopt. Good enough to love. Also? This framework doesn’t need a 3-day offsite. You can use it in a pinch. Use it for: Defining your MLP
Choosing a user segment to go after
Deciding between features when engineering is short-staffed
Roadmap planning
Arguing with stakeholders in style Defining your MLP Choosing a user segment to go after Deciding between features when engineering is short-staffed Roadmap planning Arguing with stakeholders in style The VITALS framework VITALS framework Why VITALS works It’s user-centric Starts with value. Ends with simplicity. You’re thinking about the people using it — not just building it. It’s business-aware You’re not solving for feel-good ideas. You’re moving a metric. You’re aligning to something bigger than the feature. It’s engineering-respectful You’re asking the big “Can we actually do this?” question before your team burns two sprints rage-building something half-baked. It scales You can use this when: You’re defining a feature set for v1
You’re building something new from scratch
You’re mid-iteration and need to make hard trade-offs
You’re in a big org or a scrappy one
You’re launching in B2B or B2C or D2C or IDK You’re defining a feature set for v1 You’re building something new from scratch You’re mid-iteration and need to make hard trade-offs You’re in a big org or a scrappy one You’re launching in B2B or B2C or D2C or IDK How to use VITALS (without building another spreadsheet) You don’t need a 12-tab Excel doc to use VITALS. This isn’t a math test. Here’s how to make it actually work for you in the real world. Step 1: Write your options down Could be solutions, features, user segments, or even GTM bets. Put them side by side. No overthinking. Step 2: Score each option against VITALS Use a 1–5 scale (1 = not strong, 5 = strong). Be honest. Gut check is good enough to start. Step 3: Total it up baby You can go the weighted score route if your org loves numbers. Or you can look at where something shines or fails. The point isn’t just to let the score decide — it’s to also surface what matters and have a better conversation. Step 4: Gut check and align Circle the ones that score well and feel right. Then align with your team. VITALS doesn’t replace your product intuition. It supports it. and Step 5: Use it everywhere Trying to define an MLP? VITALS.
Choosing between five solutions? VITALS.
Debating feature cuts before launch? VITALS.
Planning the next quarter? VITALS. Trying to define an MLP? VITALS. Choosing between five solutions? VITALS. Debating feature cuts before launch? VITALS. Planning the next quarter? VITALS. If it feels like overkill, scale it down. Use just V-I-T. Or do it on a whiteboard with sticky notes. The tool is flexible. The point is clarity. Want to see it in action? Let’s day you have a problem statement that you need to solve. “Design a mobile experience to improve the experience of drivers during heavy traffic in urban cities.” “Design a mobile experience to improve the experience of drivers during heavy traffic in urban cities.” “Design a mobile experience to improve the experience of drivers during heavy traffic in urban cities.” Step 1: Choose your user segment using VITALS Let’s break down the potential user segments for this problem And now, let’s use VITALS to choose one of the segments that we will implement the solution for! Step 2: Choose your solution using VITALS So, now thinking of solutions*,* this is what we might have. Now, when it comes to choosing a solution, we can again use VITALS. Step 3: Choose MLP features using VITALS Alright! We have chosen the Flexi-route wallet option and now it is time to determine the features that will be a part of the MLP launch. And this is how I would go about using this framework! Want to go one level deeper? Use VITALS as a team exercise. team exercise Everyone scores each option silently. Then compare. Now you’re not arguing opinions — you’re aligning on inputs. If someone says something should score a “5” on Value Fit, ask “why?” (To be honest, you might not even agree with my scoring and that is fine!) (To be honest, you might not even agree with my scoring and that is fine!) You’ll learn what they know. You’ll surface blind spots. You’ll finally stop pretending that prioritization is a solo sport. Final thought VITALS may not be perfect. But it’s real. VITALS may not be perfect. But it’s real. I built this framework because I was tired of frameworks that looked good in slides but fell apart in stand-ups. It’s designed for Minimal Lovable Products. It respects the user, the business, and the team doing the work. user business team And most importantly — it helps PMs move from*“What can we do?”* to “What should we do?” “What should we do?” So the next time you’re stuck in roadmap limbo or sprint debate purgatory, there’s only one thing to say: 🩺 “Let’s check the VITALS.” “Let’s check the VITALS.” Try it. Break it. Tell me what didn’t work. We’re all just trying to build better — and I’d love to hear how you made it yours.

This story contains new, firsthand information uncovered by the writer.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Every

Everything I Wish I Knew Starting Out as a New Product Manager

Let’s Check the VITALS: a PM’s Framework for Prioritizing What Actually Matters

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Everything I Wish I Knew Starting Out as a New Product Manager

Everything I Wish I Knew Starting Out as a New Product Manager

10 Prioritization Techniques for Agile Product Development

4 Reasons You Shouldn't Use MoSCoW for Product Prioritization

How To Priority Matrix 😈 Stop Using Product Roadmaps And Use THIS Instead

I Built a Product with a No-Code Tool and Pitched it to VCs

Everything I Wish I Knew Starting Out as a New Product Manager

Everything I Wish I Knew Starting Out as a New Product Manager

10 Prioritization Techniques for Agile Product Development

4 Reasons You Shouldn't Use MoSCoW for Product Prioritization

How To Priority Matrix 😈 Stop Using Product Roadmaps And Use THIS Instead

I Built a Product with a No-Code Tool and Pitched it to VCs

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps