MVP (minimum viable product) in Internal Product Management?

Currently in Project Management, we currently work with internal teams on how to solve problems for them but we don’t create an “MVP” per se. I am trying to understand how would an MVP look like in Internal Product Management? Do you/firms usually make a prototype for internal products and validate if that indeed solves the problem? Does that add value in your opinion? How has your experience been?


It’s the same idea - minimum viable product - what the simplest/smallest product you can build that will make your user’s life easier?


Or, what is the smallest thing you can build that validates the underlying assumptions of success without overinvesting limited resources


Here’s my favorite article about MVPs and changing the language to be more intuitive.

Changing to “Earliest testable product” “earliest usable product” and “earliest loveable product” has really helped align teams in my startup. I figure some people here would find it useful as well. I quite enjoy the benefits of the change in language here, hopefully it applies to OP or others as well! Works great for internal products from my experience.


Here’s an example MVP we’re doing - end goal is we want to leverage an API call to access specific data and be able to write SQL queries to determine eligibility on that data. Our MVP is hard coded eligibility using the API. Phase 2/post MVP will be user-configurable SQL using the API.


Yes we do create mockups of our planned internal tools/products and get feedback from users before we start building anything. We also perform usability testing with internal teams to ensure things are working intuitively and identify areas for future enhancements. We have bi- weekly sprint reviews with a group of stakeholders who use our internal tools so we get continuous feedback as the features evolve. This has definitely helped us identify major gaps and minor tweaks we could make to significantly improve user satisfaction.


Start with “show me your spreadsheets you use to manage this”, then figure out how to consolidate and remove steps (retool is a wonderful and fast way if you have limited/no dev resourcing).


Internal products can often be just an Excel spreadsheet or built from another tool (not just from scratch). This is then validated by pilot users based on a persona, or simply who you expect would try it first.


Talk to the users - See what they currently are doing as a workaround. Find out the root problem and hear out their ideas. Get a feel of the team, how tech savvy are they?

Once you figure the above - spin up an MVP. We use a lot of different products for the first version of the product.

Here are a few -

Microsoft Forms



SharePoint Lists

Power Automate


and a couple other no / low code tools.

The MVP for us acts as an experiment -

How are the users interacting with it?

Can we decrease the learning curve?

What problems are we seeing?

What problems are the users now not having?

What problem are they now seeing?

Should we spin up a V2 and if so, when?

How can the V1 continue to scale?

Did it solve the initial problem the team was facing?

A lot of internal PM work is not the best, when it comes to deploying PM best practices. A lot of the time, we do not and it really bugs me.

MVPs, internally def add value. It alleviates Developers from a lot of work. A lot of co’s call them self agile, but end up building internal products following a waterfall approach.

Currently, an internal team decided to not reach out to our team, when it came to rolling out a new product. They just reached out last week, so we can administer, support, and develop said product.

If they would have reached out, we would have done research / experiments, before building anything. We would have collaborated with our ITSM team to spin up an ‘MVP’ ticketing system.

Internal PMing can be fun. If internally PM principles are being followed. If not, you just become a feature creating machine, without learning the why.

1 Like

With Internal Product management the best thing is that your feedback loop is small. You can involve your users starting from the design validation and perform rigorous exercise on understanding how the user behaves or reacts to the mock ups. You can perform usability testing extensively to see which idea is working and which one isn’t.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.