Sedicii’s Product Development Strategy: Building What Customers Need vs. What They Want

Sedicii’s Product Development Strategy: Building What Customers Need vs. What They Want

Every enterprise startup faces the same trap: your first customers need custom features to close deals, so you build them. Then the next customer needs different custom features. Before long, you’re maintaining a Frankenstein product that’s impossible to scale and doesn’t serve anyone particularly well.

In a recent episode of Category Visionaries, Rob Leslie, Founder & CEO of Sedicii, explained how his team navigated this exact challenge while building institutional crypto custody infrastructure. “We were very customer-obsessed from the beginning,” Rob says. “We would basically build whatever our customers needed.” But he immediately adds the critical caveat: “You can’t just build custom stuff for every single customer. You have to figure out what the common problems are and build products that solve those common problems.”

That tension—between solving individual customer problems and building scalable platform capabilities—defined Anchorage’s entire product development approach. Getting it right was the difference between becoming a consulting company that happened to sell software and becoming a true platform that could serve hundreds of institutional clients.

The Early Stage Paradox

When Anchorage started selling to institutions, they had no choice but to be flexible. They were asking major financial institutions to trust a startup with custody of digital assets worth millions or billions of dollars. These weren’t customers who would accept a take-it-or-leave-it product offering.

“We had this thesis early on that institutions were going to be the ones that were going to drive this industry forward,” Rob explains. “And so we focused exclusively on institutions from day one.” That focus meant building for customers with sophisticated, non-negotiable requirements around security, compliance, and operational workflows.

Early customers effectively became product co-creators. They would explain their custody workflows, their risk management frameworks, their compliance needs. Anchorage would figure out how to translate those requirements into product features. “We spent a lot of time educating the market on what custody is, why it matters, what the risks are,” Rob says. But the education flowed both ways—customers were teaching Anchorage what institutional-grade custody needed to look like.

This created tremendous product velocity in one sense. Every customer conversation generated new feature ideas. The product roadmap was never empty. But it also created a dangerous temptation: to keep saying yes to custom requests because that’s what closed deals.

The Network Effect of Customer-Driven Features

The genius of Anchorage’s approach was recognizing that not all customer-driven features are created equal. Some requests were truly unique to that customer’s specific situation. But most requests, properly understood, represented common institutional needs that just happened to be articulated differently.

“Every time we added a new feature, it made the product better for everyone,” Rob explains. This is the key insight that separates successful enterprise platforms from glorified consulting businesses. When you build a feature for Customer A, you should be building it in a way that also solves problems for Customers B, C, and D—even if those customers haven’t articulated those problems yet.

This required a specific kind of product thinking. When a customer requested a feature, the product team couldn’t just build exactly what was asked for. They had to understand the underlying problem, identify how that problem manifested across different customers, and build a solution that addressed the general case while still solving the specific request.

For example, different institutions might have different approval workflows for authorizing transactions. One hedge fund might require two authorized signers. A bank might require three signers from different departments. A family office might have a different structure entirely. The naive approach would be to build custom approval logic for each customer. The platform approach is to build flexible multi-signature capabilities that can accommodate any institution’s approval workflow.

Saying No Without Losing the Deal

The hardest part of customer-driven product development isn’t saying yes—it’s learning when and how to say no. Rob acknowledges this directly: “You can’t just build custom stuff for every single customer.” But how do you say no to feature requests from customers you desperately need?

The answer lies in the distinction between solving customer problems and implementing customer solutions. When a customer asks for a specific feature, they’re often proposing a solution to an underlying problem. Your job as a product builder is to understand that problem and determine if there’s a better, more generalizable solution.

This means having deep, consultative conversations with customers about why they need what they’re asking for. What problem are they trying to solve? What constraints are they operating under? Are there other ways to address the same need? This consultative approach serves double duty—it helps you build better products and it positions you as a trusted advisor rather than an order-taker.

Sometimes you’ll discover the customer’s proposed solution makes sense and you should build it. Sometimes you’ll find an alternative approach that solves their problem better. And sometimes you’ll decide the request is too specific to their unique situation and doesn’t belong in the core platform.

The key is making these decisions through the lens of platform thinking: will this feature make the product better for our current customers and more valuable for future customers? If yes, build it. If it only solves one customer’s unique problem, find another way to help them.

The Transition from Flexibility to Standards

As Anchorage scaled, their product development approach had to evolve. “In the beginning, it was just us,” Rob says. “We were the salespeople, we were the product people, we were the customer support people.” In those early days, you can afford to be maximally flexible because the founders are involved in every customer conversation.

But as the team grew and the customer base expanded, maintaining that level of customization became impossible. This is when product discipline becomes critical. You need to establish standards for what you will and won’t build. You need processes for evaluating feature requests. You need to be able to tell customers no while keeping them happy.

Rob describes building methodology into the sales process: “You have to have a way of qualifying leads, a way of moving them through the funnel, a way of closing deals.” But methodology is equally important on the product side. You need frameworks for deciding what gets built, how features get prioritized, and when to sunset capabilities that no longer serve the platform vision.

This doesn’t mean you stop listening to customers. “We were very customer-obsessed from the beginning,” Rob emphasizes. But customer obsession at scale looks different than customer obsession at startup stage. You’re looking for patterns across your entire customer base rather than optimizing for individual accounts.

When Platform Thinking Meets Regulation

One area where Anchorage’s approach to product development became especially important was regulatory compliance. “We always believed that regulation was coming and that the companies that were prepared for it were going to be the winners,” Rob says. This conviction shaped how they thought about building platform capabilities.

Individual customers might have different compliance requirements based on their jurisdiction, asset types, or regulatory status. The temptation would be to build custom compliance workflows for each customer segment. But Anchorage recognized that regulatory requirements, while varied in specifics, share common patterns.

This insight led them to pursue a federal banking charter—a decision that took enormous investment. “We spent probably two years working on getting our charter,” Rob reveals. “It was a massive undertaking.” But the charter allowed them to build compliance capabilities at the platform level that served all customers, rather than maintaining separate compliance systems for different customer types.

“Having that charter opened up a lot of doors for us,” Rob explains. “It gave us credibility with institutions that otherwise would have been very skeptical.” More importantly, it meant they could build compliance into the platform foundation rather than bolting it on customer by customer.

The Compounding Returns

The ultimate validation of Anchorage’s product development approach came through customer referrals. “Once you get a few customers, they start referring you to other customers,” Rob notes. But this only works if you’re delivering exceptional experiences. “You have to make sure you’re delivering a really good product and really good service.”

The product decisions they made early on—building platform capabilities rather than one-off customizations—enabled them to deliver consistent quality at scale. New customers benefited from features built for previous customers. The platform got stronger with each implementation, not more fragmented.

For founders building enterprise infrastructure, Anchorage’s approach offers a clear framework: be obsessively customer-focused in understanding problems, but maintain discipline in how you solve them. Build features that serve the many, not just the one. And always ask whether what you’re building today will make your platform more valuable tomorrow.

The companies that win in enterprise don’t just solve customer problems—they solve the right customer problems in the right way, creating platforms that compound in value rather than complexity.