From “maybe” to “must-fund”: building a proof of concept that secures buy-in and budget

Key takeaways: A proof of concept and a prototype answer two different questions. A PoC proves something can be built. A prototype proves it’s worth building. Founders who confuse the two often walk into budget conversations with the wrong evidence. Effective proof-of-concept prototyping treats the PoC as a shared story, not a private experiment, so the whole team reaches the same understanding before anyone asks for money.

You can build almost anything now. That part isn’t in question anymore. What’s still hard, maybe harder than ever, is knowing whether what you built is worth funding.

Kendra Wilkins has spent a career answering that question. As Product Director for Miro Prototypes, she’s watched teams go from spending weeks on a single build to spending hours, and she’s watched the bottleneck move with them. It didn’t disappear. It just moved from “can we build this” to “should we, and how do we prove it.”

“We will have AGI, and it will still be impossible to get six people in a room to align,” Wilkins said at a recent Miro Canvas 26 session, quoting a comment she’d heard from a leader at Anthropic. It got a laugh from the room. It also landed, because most people building products right now feel the exact same friction. Tools have gotten radically faster. Decisions haven’t.

That gap is exactly where a proof of concept either earns its keep or wastes everyone’s time. Closing that gap doesn’t take more time. It takes a sharper proof of concept, and a clearer idea of what that proof is actually supposed to do.

Watch Kendra explain it live:

Kendra Wilkins covers this exact tension, and demos how it plays out on the canvas, in her Miro session on moving from concept to validated direction.

What a proof of concept is actually for

A lot of founders use “proof of concept” and “prototype” like they’re the same thing. According to Wilkins, they’re not, and mixing them up is one of the more expensive mistakes a startup can make.

“The distinction is in the job to be done and the desired outcome,” Wilkins said. “A PoC is about understanding early technical feasibility: if we wanted to build it, could we? How could it work? The outcome of a PoC is to understand if it’s even technically possible.”

A prototype is a different animal entirely. “A prototype helps you understand what resonates, what’s missing, and what you need to evolve before actually building: am I building the right thing? The outcome is an interactive, real-feeling version of what your product could be so that you can refine and validate before you start executing.”

Put simply: a PoC answers “can we.” A prototype answers “should we, and what should it look like.”

Skipping the PoC and jumping straight to a polished prototype is where things go wrong for complex or technically ambitious ideas. “You might fall in love with a version of your product that you can’t actually build, or that takes so much time and effort to build that you lose out on ROI,” Wilkins said. A PoC exists to surface those limitations early, before a team has emotionally and financially invested in a direction that was never realistic.

So when do you stop testing feasibility and move toward something closer to a real prototype? Wilkins’s answer is refreshingly direct: “You feel confident that you understand and are willing to take on the level of technical complexity required to bring the idea to life.” Not when the deck looks good. Not when the deadline hits. When the team actually understands the size of the problem it’s signing up for.

What investors and leadership are actually evaluating

Once you know what investors are actually judging, hitting that bar gets a lot more achievable. The mistake most founders make is assuming an investor is judging your PoC the same way an engineer would. They’re usually not.

“Investors and the team should ask: does this solve the problem well enough to move forward with the concept?” Wilkins said. “And maybe secondarily: does this align with our mission and strategy?”

That’s a different bar than “does the code run.” It’s closer to: is this worth continuing to invest time and money in, given everything else this team could be doing instead?

This is also where Wilkins’s now-famous line from her keynote applies directly to fundraising. “Just because you can build it, doesn’t mean you should ship it,” she said onstage, a note she credits to her manager, Jeff Chow, Miro's CTO. In our interview, she extended that idea to the funding conversation itself: “It can be really hard to not build the thing the investor is asking for. But it’s really important to know when the investor is your customer and when they aren’t. You should be shipping products that customers use and value enough to pay for. I always say: you can have the most beautiful, impressive product in the world. If nobody uses it, it doesn’t matter.”

That distinction, between building for the investor in the room and building for the customer who eventually has to want it, is one founders underestimate constantly.

Wilkins has lived this from the other side of the table too. At Joyn, the startup she co-founded, a proof of concept became the thing that landed the company’s largest customer. “Customers had started to ask about how we structured and understood the context needed to power Joyn,” she said. “We realized that they not only saw value in what Joyn was creating but also saw value in the how, and wanted to leverage it within their own data and architecture. We built a PoC that visualized how our context graph worked, and the customer was so impressed, they were asking how they could use it ASAP.”

Notice what actually convinced the customer. It wasn’t a finished, polished product. It was a PoC that made an abstract, technical concept suddenly visible and understandable.

As for how deep into the technical weeds a PoC needs to go before it’s convincing, Wilkins keeps the bar practical rather than exhaustive: “You need the big bets to be validated, you don’t need to solve for all of the edge cases. You’re really trying to focus on understanding: how could we solve this? If we solve it this way, does it solve the problem well enough? How complicated is it to bring to life, and what risks are we taking?”

Alignment is the real multiplier

If there’s one thread running through everything Wilkins says about proof-of-concept prototyping, it’s this: the technical proof matters, but the alignment it creates matters just as much, if not more.

“A PoC helps you tell the story,” she said. “Reading a product brief or PRD can give you valuable context for sure, but seeing the thing actually solve the problem, that gets you to shared context very quickly. A great PoC tells the story of why and how in one quick demo. Alignment is about shared context and building consensus, and a PoC gets you to that shared context in a way humans can easily understand.”

This tracks with something Wilkins said during her keynote about why AI hasn’t solved the hardest part of building products. Teams have more tools than ever to build faster, but not many that help them decide faster. A PoC, done well, is one of the few artifacts that can actually close that gap, because it turns an abstract idea into something a room full of different roles can react to at the same time.

That’s also why Wilkins pushes back on the instinct to build one version and defend it. In her keynote, she made the case for exploring multiple directions at once: when a team only considers one option, that option usually wins by default, whether or not it was the best one. The more directions a team can see quickly, the higher the odds of landing on the right one.

She extended that logic directly to PoCs in our interview. “A PoC should not feel like a one and done, but the approach depends on the complexity of the problem and the solution,” she said. “In almost every case, you have at least three great ways to solve the problem, most likely more. You should explore them all. You should be thinking of the ROI of each PoC: what do you learn that’s valuable if you build it? What is the outcome of knowing whether or not this approach is feasible? If you need three in order to choose a path forward, build three. If you have conviction on one direction, build one. Just make sure you aren’t attaching your loyalty to the solution. Your loyalty should always be to the problem.”

That last line is the one to hold onto. It’s easy to fall in love with the thing you built. Wilkins’s advice is to stay in love with the problem instead, and let the PoC work be in service of solving it, not proving you were right from the start.

Rebuilding the pause AI took away

There’s good news buried in a real problem here. In her keynote, Wilkins talked about how the old handoff moments between PMs, designers, and engineers used to double as natural check-ins, moments where someone would pause and ask if the team was actually making the right call. As AI collapses those handoffs, that built-in pause can disappear with it. The fix isn’t complicated, though: build the pause back in on purpose, and it works even better than the accidental version ever did.

Her fix isn’t to slow down. It’s to build the check-in into the process on purpose. “Celebrate the challenger mindset and tell the story of how you got from A to B to Z with shared context,” she said. “Make the goal of the PoC and/or prototype clear, and always call out your assumptions and risks. If you state your assumptions and the known trade-offs, and make it clear what you’ve considered and decided not to pursue, you give your team permission to challenge and present alternatives, and if they have the right context, their feedback can be incredibly valuable and actionable.”

In other words, the PoC itself needs to carry the pause. What was once a hallway conversation now has to live inside the artifact.

And feedback isn’t just a formality on the way to consensus. It’s often where the real improvement comes from. “I’d be surprised if your first version is your best version,” Wilkins said. “In fact, I’d bet it never is. Gathering feedback from different perspectives and exploring different ways to solve the problem only makes your solution better. There’s beauty and value in the unexpected comment or the feedback that sparks an idea that might not have come from the first iteration. That’s how great products are designed. Consensus isn’t the goal, but it is a necessary outcome. The goal is getting to the best solution you can, harnessing the power of you, your team, and your tech.”

So how do you know a PoC has done its job? Wilkins’s answer is grounded, not theoretical: “Easiest answer: people are asking to use it. Or generally: when you have conviction that it solves a meaningful problem well enough for a group of customers and users to use and/or pay for it, and that it’s the most impactful thing your team could be building.”

Bringing scattered ideas onto one canvas

Most founders aren’t starting from a blank page. They’ve got a Figma file here, a Confluence brief there, maybe a working prototype someone built in Claude Code over a weekend. Wilkins showed exactly what happens when that scattered context lands in one place instead of staying split across tools.

In her keynote demo, she dragged an HTML-based prototype straight onto a Miro board and started editing it live, right there with the audience watching. “One of the challenges, if you are building a prototype in one of these tools, is you either have to record a video and share it out, or you have to host it in order to share it out,” she said. On the canvas, the team can edit copy, rearrange components, and generate variants together, without any of that extra overhead.

She also connected a live Confluence product brief to a prototype using Miro Flows, so that when the brief updated mid-build, the prototype could update along with it. That’s a meaningful shift in how to think about a proof of concept. It doesn’t have to be a frozen snapshot. It can stay connected to the context that’s still evolving around it, and update as that context changes.

Asked why this matters beyond convenience, Wilkins pointed to something more fundamental about how humans process information. “You are visualizing the story on the canvas in a way that our human brains can understand almost instantly,” she said. “Agents are excellent at processing vast amounts of text and information: they love a long, verbose markdown file. Humans are great at understanding visual relationships, seeing how the different artifacts connect and fit together. Having it in a shared canvas helps us tell the full story of what the idea is and why.”

That distinction matters more than it might first appear. AI agents can synthesize enormous volumes of text. But the people in the budget meeting, the ones who actually decide whether to fund something, need to see how the pieces fit together, not read another document about it.

Wilkins also demoed generating multiple prototype variants from the same starting point, then watching the team leave comments across both, some liking a chart in one version, some preferring the navigation in the other. Rather than picking a winner outright, the team pulled pieces from each into a stronger combined version. That’s the alignment principle in action: consensus wasn’t the goal, a better solution was, and the variants got them there faster than a single “final” draft ever could.

The decision artifact: what actually walks into the budget meeting

Once a team pulls those comments together into a refined version, something else happens on the canvas: a decision artifact gets generated. It’s not just another draft. It’s a record of what got decided and why.

“It logs the most critical decisions so that when we get to the budget ask, you know exactly what the budget unlocks, what trade-offs were made and acknowledged, and what decisions were locked in to unblock the build,” Wilkins explained. “This is your record-keeper so that everyone is making that budget call with shared context and understanding of why this needs to get funded.”

That’s a meaningfully different artifact than a slide deck built the night before a pitch. It’s a running history of the decisions, trade-offs, and alternatives a team already worked through, so the people approving budget aren’t being asked to trust a demo. They’re being shown the reasoning that got the team there.

How to build a proof of concept that actually secures budget

Wilkins’s approach breaks down into six practical steps:

1. Start with the risk question, not the build. Before opening any tool, define what you’re actually trying to learn: is this technically possible, and what would it cost in time and complexity to find out?
2. Explore more than one direction if the problem calls for it. If you need three approaches to choose a path forward, build three. Don’t commit to a single direction just because it’s the first one you thought of.
3. Bring scattered context into one shared space. Whether it’s a Figma file, a product brief, or a working build from Claude Code, get it all onto one canvas where the whole team can react to it together, not just read about it separately.
4. Invite the friction back in on purpose. State your assumptions and the trade-offs you’re aware of. That’s what gives your team permission to challenge the direction constructively, instead of quietly disagreeing after the meeting.
5. Let feedback reshape the solution, not just validate it. Comments and variants aren’t a formality before sign-off. They’re often where the actual improvement comes from.
6. Capture the decision, not just the demo. A record of what was decided, what trade-offs were accepted, and what the budget actually unlocks carries far more weight in a funding conversation than a polished walkthrough alone.

The bottom line

The shift worth making is simple: stop treating a PoC as something you build alone and hand over when it’s done. The strongest proof-of-concept prototyping builds a shared story as it goes, one the whole team, and eventually the people holding the budget, can walk through together and reach the same conclusion on.

Wilkins’s advice keeps circling back to the same idea: stay loyal to the problem, not to any single solution. Explore more than one direction when the problem calls for it. Invite feedback in on purpose instead of hoping it surfaces later. And when it’s time to ask for the resources to build the real thing, walk in with a record of the decisions already made, not just a demo that still needs explaining.

Get that right, and the budget conversation stops being a pitch. It becomes a formality.

Frequently asked questions

What’s the difference between a proof of concept and a prototype? A proof of concept tests whether an idea is technically possible to build. A prototype tests whether the idea, once built, is the right one, showing what resonates with users before a team commits to full execution.

How do you prove technical feasibility to investors? Focus on validating the big bets rather than every edge case. Show how you’d solve the core problem, whether that approach solves it well enough, and what complexity and risk come with bringing it to life.

What makes a proof of concept fundable rather than just functional? A fundable PoC creates shared understanding across the team and the people approving budget. It tells the story of why a direction works, not just that the code runs, and it comes with a clear record of the decisions and trade-offs behind it.

Should a startup build one proof of concept or several? It depends on the complexity of the problem. If choosing the right path forward requires comparing options, build multiple. If there’s already strong conviction on one direction, one well-built PoC can be enough. The loyalty should always be to solving the problem, not to any single solution.

Try it yourself

If your team is sitting on a scattered pile of Figma files, product briefs, and half-built ideas, that’s usually where proof-of-concept prototyping starts to break down before it even gets off the ground. Bring it all onto one Miro Prototypes canvas, invite your team to react to it together, and see what a shared decision actually looks like before your next budget conversation.

Last updated: July 15, 2026