Claire Vo

I was CPO at Blend before their $4 billion IPO. We rejected the “forward deployed engineer” Palantir model that everyone is copying now. Here’s why: Blend could have followed the forward-deployed engineer approach. Both our CEO and CTO were early Palantir. They'd seen it work. Instead, we built a SaaS product with core components. Move fast, iterate, use data to learn. Not custom code for every client. That Palantir model is having a resurgence. Now Sierra, Decagon, and others are hiring forward-deployed engineers. But it’s not the right approach for every company. It’s fundamentally the wrong answer for Assembled’s customers. Here's what we understand about support teams and why we’re not going the forward deployed route: Customer Support teams are used to getting no resources and no support. On the surface, you'd think they'd be excited about engineers building custom solutions. "Finally, someone's offering us developers!" The reality is support teams are terrified of getting help they can't afford to keep. Support teams are wary because they know the math. They don't have budget for expensive, scarce resources. At some point the shoe drops. The engineers disappear when priorities shift. And custom solutions break. Support is left holding the bag with something they can't maintain. They're resource-starved by design. The idea of a dependency on resources they can't control is terrifying. So instead, the goal should be to give support teams the ability to manage, change, and solve their own problems. Not dependencies on engineers they can't keep. Smart, competent people who teach them to do it themselves. Palantir wasn't even a product company for years. They were a custom development shop with reusable components. Show up, build something bespoke, maybe extract learnings. That's not scalable for any but the largest support teams who need sustainability. Forward-deployed engineers are the new shiny object. I wasn’t a fan of it at Blend. And I’m not a fan today either. What I see in the customer support space is that teams need empowerment, not dependency. I want the teams we work with to be able to say: "I love that you’re partnering with me. And I love that I can do this myself too." That's the difference between building a product and building a consulting practice.

80

6 Comments

Most teams don't struggle with speed anymore. They struggle with building the right things. That's exactly where my brother thrives. He's a Principal Product Designer who brings real product thinking into design. The kind of person who helps teams cut through complexity and focus on what matters. If you're building serious products and need that level of thinking, take a look at his post below.

5

2 Comments

Leading product at Haast, I've seen skepticism that surrounds AI firsthand, especially when it comes to legal and compliance. In this space, speed isn't enough. Enterprises demand accuracy, explainability, and reliability—without compromise. Building our product is more than great design and code. It requires training AI on real-world compliance scenarios, partnering closely with legal experts, and embedding human-in-the-loop validation at every step. That behind-the-scenes rigor is what makes the difference. Our AI not only flags risks, but also explains *why* they are risks, referencing the exact policy or regulation. We’ve baked transparency and data security into the product from day one, because in compliance, trust isn’t a feature, it’s the foundation. Curious to hear from others: What’s your biggest trust barrier when evaluating new AI-powered tools? #ProductLeadership #AIEthics #EnterpriseSoftware #TrustInTech

30

Highly recommend watching this episode from Lenny Rachitsky's podcast with the one and only Jeanne DeWitt Grosser (COO of Vercel) on the future of GTM in an AI world. She provides a deep dive into how Vercel is using AI to benefit their sales org today. Must watch.

14

The division into Product, Design, and Engineering was a detour. Marc Andreesen recently called what's emerging "super empowered individuals". Tomer Cohen calls them Full Stack Builders. The less optimistic term making the rounds is "role collapse." I think we're just returning to an older word: Builder. For most of human history, someone with a vision made it real. The craftsman who designed the chair also built it. Then came scale. Especially in software the number of steps and knowledge required to ship something simply grew beyond what one mind could hold. We needed specialists. Now the constraint is dissolving. People with the title "Designer" and "Product" can all do the same thing: ship a solution to production. They see something that should exist and make it real. When founders start companies, they don't dream of org charts. They don't want roles and dependencies and handoffs. They want a solution in the world. Now we can finally see a path to making that happen. Use AI. Be a Builder.

27

2 Comments

Product + Partnerships: Not a Handoff. A Handshake 🤝 I had the privilege of speaking at Catalyst in a wonderful Seattle, an incredible gathering of partnership leaders - and the perfect place to reframe how product and partnerships should work together. Too often, product teams operate in isolation: talk to customers, build features, ship. But when you’re building a platform, that’s not enough. Real value is co-created - by customers, developers, and critically, by partners. Here are the five principles I shared with the Catalyst audience - ones I believe every product and partnership leaders should rally around: 1. Shared North Star Align on who you're building for and why. Ideal customer profile, strategic focus, and desired outcomes must be shared - not assumed. 2. Intentional Ecosystem Strategy Great product strategy isn’t just about what you build - it’s about what you intentionally don’t, so partners can innovate, specialize, and scale customer value. 3. Early Collaboration Bring partnership teams in before roadmaps are set. They know what’s working in the market, what gaps customers are filling themselves, and where a “build vs. partner vs. buy” conversation is overdue. 4. Shared KPIs Whether it’s revenue impact, integration adoption, or retention - define success together. Own outcomes jointly. 5. Mutual Ownership When a partner fills a critical product gap, product should champion it like they built it. And vice versa. Trust and success scale when both sides act as one team. The best outcomes don’t come from one team “supporting” the other - they come from co-defining the problem space and building the solution story together. To the partnership leaders reading this: bring a chair and join your product team at the strategy table early. To the product leaders: Treat your partners like an extension of your roadmap. And I’d love to hear your perspectives... 1. What’s worked for you in building real product–partnership collaboration? 2. What’s still broken? 3. What do you wish the “other side” better understood? P.S. Thank you Asher Mathew and Chris Samila for organizing such a thoughtful and impactful event. It was a real pleasure meeting so many brilliant people and learning from each of you. And to everyone I spoke with during prep - thank you. I learned so much from your experiences, best practices, and candid reflections. You helped shape this talk more than you know, I'm really grateful for everything I learned from you. cc Lisa Hendrickson Richard Gilbert Robert Cohen Matt Dornfeld Udi Shamay Jenny Hopkins James Booker Darren Sepanek Dave Eichler Scott Richards and many others #ProductLeadership #Partnerships #PlatformStrategy #B2B #Catalyst2025 #EcosystemThinking

108

16 Comments

Today we're changing Clay's pricing. Pricing changes are scary (for you and me!), but we are trying to do this in the most authentically Clay way possible - thoughtful, transparent and community-first. We've been thinking about this for almost a year (maybe too long Karan!), and have talked to hundreds of customers and partners. We want to align our business model with how our product is being used today, and set us up to grow sustainably together. When we launched, our customers used us for data enrichment. And now our community is using Clay to power their GTM engineering motions. But the pricing model hasn't evolved, so we're making some changes to reflect that. Here’s what’s important to note: First: nobody is getting forced off their plan. Every existing customer can stay on their existing plan. We have to earn the right for you to move to a modern plan. Second: most customers will see better value for their money with this change. If we think you'll save money by switching to the new pricing, we're going to reach out and tell you proactively. Third: we're separating the cost of data from the cost of the platform. We want to keep bringing down the cost of data in Clay, and make the value tied to what you orchestrate and build with it. Fourth: our best features are now more accessible. The new Growth plan includes things that used to live exclusively on Pro at a 38% lower price. Many of our most advanced users will save thousands a year. Our plans now come with a new metric called Actions, which measures the orchestration work Clay does for you: the workflows, AI research, and logic that turns raw data into a GTM motion. 90% of customers will never hit their Actions limit. We want most people to never think about it. That way, we’re only winning if you are. Data Credits now cover just the data - and they're cheaper. We’re reducing the cost of the data in our marketplace by 50–90%, making prices comparable to what you’d pay externally. Karan and I recorded a video walking through the full reasoning and who gets affected - positively and negatively (including us – we’re taking a 10% revenue hit). If you're a Clay customer and have questions, we want to hear them! Full pricing announcement and the internal memo we sent our team below. Announcement: clay.link/nF1eKMH Internal memo: clay.link/wiw2NHK

555

130 Comments