Why Your Company Should Be Its Own First Customer (And How I'd Do It Differently)

I watched our company spend six months building a feature nobody actually wanted. The product team had imagined the perfect workflow, designed wireframes that looked clean, and shipped it with confidence. Two weeks after launch, our actual users rewired the entire thing in ways we never anticipated. We could have saved months if we'd just dogfooded it ourselves first.

This is exactly what the "Customer Zero" strategy is about, and I've become a believer. But I've also seen it done poorly—where internal usage is treated as a checkbox instead of a genuine testing ground. After reading about how one team is rebuilding their D365 Sales implementation from the inside out, I realized there's a right way and a wrong way to make your company your own test case.

The Customer Zero Concept Isn't New, But It Still Works

The idea is simple: before you sell your product to external customers, use it yourself. Real usage in a real environment surfaces bugs, usability nightmares, and architectural decisions you'd miss in a lab. It's the difference between theoretical performance and what actually happens when 50 people are clicking buttons at 9 AM on Monday.

What impressed me about the approach in this D365 case is the scope. They didn't just flip a switch and hope for the best. They mapped out specific business problems their sales team actually faced—stalled deals, slow opportunity velocity, customer churn—and built targeted solutions. That's not busywork. That's intentional validation.

The Architecture: Fields, Flows, and Progressive Complexity

The implementation plan they outlined is methodical. They started by adding 18 custom fields across two entities (Opportunity and Account), giving themselves the data model they needed to track what matters. Boolean flags for "Proposal Sent," date fields for tracking stage changes, option sets for NDA status. Nothing fancy, but it all connects to something measurable.

Then comes the orchestration layer: Power Automate flows organized by business zone. Zone A handles deal stalls. Zone B monitors velocity. Zone C owns customer health. Zone D manages document flow. Each zone has multiple flows with specific trigger conditions.

What I appreciate here is that they resisted the urge to do everything at once. The implementation order matters. You need the fields first, then the write-back flows that populate them, then the alert flows that react to them. It's a dependency graph, not a grocery list.

My Take: Good Practice, But With Questions

I like this approach in principle. The Customer Zero strategy works. But I'd push back on one thing: the reliance on manual field updates. "Checked by the rep when the proposal is sent." "Rep enters the PO number." "Rep records completion of Business Central registration."

Reps are busy. They forget. Or they update fields days later, breaking your alert logic. If you're building this for yourself, you have leverage to change rep behavior, but that's still friction. I'd want to automate more of these inputs—hooking Outlook events, pulling PO data from email attachments, integrating with your document management system to auto-populate SharePoint URLs.

That said, I understand the pragmatism. Getting the team to manually check a box is faster than building a three-step integration. You validate the logic first, automate it later.

The other thing I'd want to see is monitoring and observability baked in from day one. How many flows are failing? Which alerts are actually triggering? Are the 30-day and 60-day thresholds the right windows? Without dashboards showing flow health and alert frequency, you're flying blind.

The Harder Part: Making Your Org Actually Use It

Here's what the article doesn't address directly: getting your own sales team to adopt a new system is harder than selling to customers. Customers expect to learn new software. Your colleagues just want to do their jobs the way they've always done them.

They probably have spreadsheets. They probably have email workflows. They probably think D365 is just a glorified contact database. Convincing them that this new complexity is worth it? That's a change management problem, not a technical one.

Next Steps

If you're considering a similar Customer Zero initiative, start small. Pick one business problem that visibly impacts your team—maybe it's deal velocity or churn prediction. Build for that one thing. Get adoption. Prove the value. Then expand.

What's your experience with dogfooding internal tools? Has it caught real problems before they hit production?

Source: This post was inspired by "Customizing D365 Sales — For Our Own Sales Team (Customer Zero) Preparation" by Dev.to. Read the original article