An MVP inside a company that already exists plays by different rules

Search for "minimum viable product" and the stories that show up are usually about startups: a video, a landing page, three founders, and a hypothesis to test with strangers. That story is useful. It leaves out the more common case in Latin America: someone inside a company with years of operations who wants to try a new line, a service for existing customers, or a tool for their own team—without freezing the day-to-day or burning the brand's trust.

That is intrapreneurship in product form. An MVP is still the smallest thing needed to answer the riskiest question in the idea, with real users and real data. What changes is the table: there are customers who already know the company, systems that have been running for decades, budget cycles, security controls, and people whose job is to keep operations from falling over.

According to the nadIA survey of 402 industrial and software SMEs, among those that use artificial intelligence, 32.7% apply it in R&D and innovation. Interest in trying new things is there; the bottleneck is usually how to turn that interest into a contained experiment the organization can actually carry.

What weighs differently than in a startup

Customers and brand. The first user is often a paying customer or an internal team with an established process. A visible mistake reads as a brand failure, not as an early version. So the MVP starts with a small group and clear rules about what is promised and what is still off the table.

Legacy systems and data. The new idea almost always has to read from or write to an ERP, a CRM, or a critical spreadsheet. Ignoring that inheritance speeds up the demo and slows down the learning: the experiment ends up measuring the mockup, not the flow that matters. It helps to define from day one which system is touched, with which data, and what the fallback is if that integration fails.

Internal politics and a sponsor. Without someone who can unblock priorities, the MVP competes with the usual backlog and loses. The sponsor does not have to be technical; they have to be able to say the experiment has a date, an owner, and protection from other urgencies. In return, the team owes them frequent demos and an explicit decision at the end of the cycle.

Budget cycles. Many companies approve spend once or twice a year. An MVP that asks for a year of development hits that rhythm hard. One that asks for a short stretch, with a ceiling on effort and a kill criterion, gets funded as a test rather than as an endless project.

Compliance and security. Customer data, access rights, and logs show up in week one. Treating security as paperwork for later often freezes the pilot right when it starts to produce signals. The practical move is to bound the perimeter: which data comes in, who sees it, where it lives, and what stays explicitly out until there is evidence of value.

Who owns it. If the MVP "belongs to everyone," nobody prioritizes it when an operational fire breaks out. It needs a business owner (which problem is being solved and which number matters) and a technical owner (what gets built, how it runs, and how it gets shut off if something goes wrong).

Permission to experiment, without opening the whole company

Permission rarely arrives as a blank check. It arrives when the proposal answers, in writing, four points: what will be learned in one measurable sentence; what is left out on purpose; who uses it first and for how long; which number decides whether to scale, adjust, or stop.

That short document is the contract of intrapreneurship. It reduces the urge to keep adding requests from every area until the "minimum" looks like the full product. It also gives the sponsor something concrete to defend against other priorities.

Three filters help choose the scope: if part of the work can be done by hand for the first few weeks, that part waits; if the pilot group does not fit in a single meeting, the scope is still too wide; if the experiment touches three systems and four areas at once, political and technical risk multiply together.

The success number is agreed beforehand

Without a number agreed in advance, the pilot stretches by inertia: there is always one more feature or one more week of adoption. The number has to be about the business or the operation: orders that go through the new channel, response time, error rate, people on the team who come back to the tool in the second week.

The same agreement includes the decision date and the three possible outcomes: expand, adjust, or stop. Stopping is a valid result. An MVP that shows the idea does not hold saved the year of building that would have come next.

How adoption works when the team already has another way of working

In companies with development teams that have years of history, an MVP collides with long tickets, infrequent releases, and fear of touching what already works. Asking that same team to abandon its rhythm overnight usually stalls the experiment. A contained parallel lane works better: the same technical owner, weekly demos, real data, and an explicit rule that nothing merges into the main system until after the scale decision.

On the internal-user side, generic training helps little. Sitting with the person who does the job, looking at the ugly cases, and adjusting the flow in front of them helps more. If the pilot depends on everyone adapting on their own, the success number almost never moves.

What changes when AI speeds up development

For years, the limit of an MVP was how much each screen and each integration cost. With AI tools, a usable version can appear in far less time. That enables more experiments per year. It also opens a trap: because building is faster, it is tempting to build too much and postpone the hard question.

When development stops being the only bottleneck, judgment becomes the scarce resource. Choosing the hypothesis, the perimeter, the pilot group, and the cutoff number takes someone who understands the business as well as the technology. The technical challenge is still there, in a different shape: the solution has to be cheap to run while it is being validated, easy to iterate when the first lessons arrive, and built with security care from the first access to real data. Moving fast without those cares produces pretty demos and expensive debt.

What it looks like in practice

On Ambolt's MVP projects, the pattern that best sustains intrapreneurship is working in short cycles on real data, with a demo every week in front of the people who will use the product and in front of the sponsor. Each demo corrects course before the detour gets expensive. The success number that will say whether the idea works is also agreed from the start, along with what happens if it is not confirmed. That clarity turns the experiment into a business decision, rather than a project that stretches because time was already spent.

Conclusion

The MVP became associated with startups because uncertainty there is total. Inside a company that already exists, the uncertainty is different: the question is whether the idea survives contact with real customers, legacy systems, internal controls, and teams that already have a way of working. Treating that context as noise leads to a pilot that never scales. Designing for it from the start—sponsor, perimeter, security, success number, and a cutoff date—turns intrapreneurship into a habit: more ideas tested per year, and fewer large bets made blind.

Frequently asked questions

What is a minimum viable product (MVP)?

The simplest version of a product or service that lets a team test an idea with real users and real data. It includes only what is needed to answer the project's riskiest question.

How do you build an MVP in an established company?

Contain the scope, choose a pilot group, secure an internal sponsor, respect security and existing systems, and define a success number up front with a date to decide whether to scale or stop.

How does an MVP relate to intrapreneurship?

Intrapreneurship is pushing a new idea from inside an organization that already operates. An MVP is the product form of that push: testing with real evidence without committing the whole company up front.

What is the difference between a prototype and an MVP?

A prototype shows how something could look or work and often stays in presentations. An MVP is used for real, with real cases, and that is why it produces evidence about whether the idea works.

Does AI replace the need for an MVP?

No. AI speeds up development and makes it easier to iterate more often. Choosing what to test, with whom, and with which cutoff still depends on understanding the business and the internal context.

What if the MVP does not work?

That is a valid outcome. If the hypothesis is not confirmed, the experiment avoided a larger investment in something that was not going to work, and what was learned usually feeds the next idea.

---

About Ambolt. Ambolt is a product agency that helps companies in Latin America turn internal ideas into MVPs that get used for real, with custom technology and a focus on the business.