Documents | ProductNow's Engineering Playbook

ProductNow's Engineering Playbook

Kadhir Mani

(10 minutes)

<h2 id='14e000a2-75f1-409f-a6b3-110e9c652162'>Who are we</h2><persona-card data-name="Kadhir" data-details="VP of Engineering at ProductNow — a platform built on a simple belief: empower everyone to build products people love." data-color="#22C55E" data-image-src="data:image/svg+xml;utf8,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%20100%20100%22%20fill%3D%22none%22%20shape-rendering%3D%22auto%22%3E%3Cmetadata%20xmlns%3Ardf%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%22%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%20xmlns%3Adc%3D%22http%3A%2F%2Fpurl.org%2Fdc%2Felements%2F1.1%2F%22%20xmlns%3Adcterms%3D%22http%3A%2F%2Fpurl.org%2Fdc%2Fterms%2F%22%3E%3Crdf%3ARDF%3E%3Crdf%3ADescription%3E%3Cdc%3Atitle%3EThumbs%3C%2Fdc%3Atitle%3E%3Cdc%3Acreator%3EDiceBear%3C%2Fdc%3Acreator%3E%3Cdc%3Asource%20xsi%3Atype%3D%22dcterms%3AURI%22%3Ehttps%3A%2F%2Fwww.dicebear.com%3C%2Fdc%3Asource%3E%3Cdcterms%3Alicense%20xsi%3Atype%3D%22dcterms%3AURI%22%3Ehttps%3A%2F%2Fcreativecommons.org%2Fpublicdomain%2Fzero%2F1.0%2F%3C%2Fdcterms%3Alicense%3E%3Cdc%3Arights%3E%E2%80%9EThumbs%E2%80%9D%20(https%3A%2F%2Fwww.dicebear.com)%20by%20%E2%80%9EDiceBear%E2%80%9D%2C%20licensed%20under%20%E2%80%9ECC0%201.0%E2%80%9D%20(https%3A%2F%2Fcreativecommons.org%2Fpublicdomain%2Fzero%2F1.0%2F)%3C%2Fdc%3Arights%3E%3C%2Frdf%3ADescription%3E%3C%2Frdf%3ARDF%3E%3C%2Fmetadata%3E%3Cmask%20id%3D%22viewboxMask%22%3E%3Crect%20width%3D%22100%22%20height%3D%22100%22%20rx%3D%220%22%20ry%3D%220%22%20x%3D%220%22%20y%3D%220%22%20fill%3D%22%23fff%22%20%2F%3E%3C%2Fmask%3E%3Cg%20mask%3D%22url(%23viewboxMask)%22%3E%3Crect%20fill%3D%22%23f88c49%22%20width%3D%22100%22%20height%3D%22100%22%20x%3D%220%22%20y%3D%220%22%20%2F%3E%3Cg%20transform%3D%22translate(3%2C%20-1)%20rotate(-2%2050%2070)%22%3E%3Cpath%20d%3D%22M95%2053.33C95%2029.4%2074.85%2010%2050%2010S5%2029.4%205%2053.33V140h90V53.33Z%22%20fill%3D%22%230a5b83%22%2F%3E%3Cg%20transform%3D%22translate(29%2033)%22%3E%3Cg%20transform%3D%22translate(-15%2C%202)%20rotate(16%2021%2021)%22%3E%3Cg%20transform%3D%22translate(0%202)%22%3E%3Cpath%20d%3D%22M14%208c0%202.2-1.34%204-3%204s-3-1.8-3-4%201.34-4%203-4%203%201.8%203%204ZM34%208c0%202.2-1.34%204-3%204s-3-1.8-3-4%201.34-4%203-4%203%201.8%203%204Z%22%20fill%3D%22%23ffffff%22%2F%3E%3C%2Fg%3E%3Cg%20transform%3D%22translate(6%2026)%22%3E%3Cpath%20d%3D%22M15%2010C6.79%2010%203.02%203.88%204.22%203.12%205.42%202.35%206.1%206.6%2015%206.49c8.9-.12%209.58-4.23%2010.78-3.37C26.98%203.98%2023.21%2010%2015%2010Z%22%20fill%3D%22%23ffffff%22%2F%3E%3C%2Fg%3E%3C%2Fg%3E%3C%2Fg%3E%3C%2Fg%3E%3C%2Fg%3E%3C%2Fsvg%3E"></persona-card> We're a small team, but don't let that fool you — we ship a lot. This post pulls back the curtain on how we actually operate. By the end, you'll walk away with a clear picture of three things:<ol><li value="1" class="LexicalTextEditor-module-scss-module__vIcBXa__listItem">Our way of working — how a lean team moves fast without breaking things</li><li value="2" class="LexicalTextEditor-module-scss-module__vIcBXa__listItem">The culture that enables it — the values and habits that make it all possible</li><li value="3" class="LexicalTextEditor-module-scss-module__vIcBXa__listItem">Where I think we're headed — and why the most exciting chapter is still ahead</li></ol> Our team has seen engineering up close at Palantir, Verkada, Amazon, Google, Microsoft and more. We've taken those lessons, evolved them to meet AI where the tools actually are today, and iterated until we landed on something that works. What follows is the result of that journey. Let's start with how we code. <metric-card data-title="Team size" data-value="4" data-color="#626262" data-icon="neutral" data-width="180" data-height="80"></metric-card> <metric-card data-title="Lines of code" data-value="220,000+" data-color="#22C55E" data-icon="up" data-width="297" data-height="80"></metric-card> <metric-card data-title="Time" data-value="6 months" data-color="#EF4444" data-icon="down" data-width="290" data-height="80"></metric-card> And this isn't a simple CRUD app — our platform runs distributed workers, long-running jobs, persistent WebSocket connections, multi-stage pipelines, security and governance, and is fully SOC 2 Type 2 compliant. By any measure, that's a lot of ground covered by a small team in a short amount of time. I was told it would be as simple as I choose you Claude, but it wasn't nearly that simple for us. It was a journey — one that required rethinking how a small team could move fast without accumulating the kind of debt that eventually grinds everything to a halt. But to really understand how we got here, you first have to understand how I think about the relationship between developers and their code. <h2 id='a9da89bd-145d-43c3-bb09-fef7b3fd3a75'>How we code</h2>My time at Palantir — where I stayed through the IPO — landed me on the SDK team for Foundry. We owned service discovery, numerical formatting, conditional formatting, etc: the invisible plumbing that every other team depended on. After Palantir, I took on developer experience (as side projects) at the next two startups I joined. That's years spent thinking about one question: <callout icon="megaphone" color="#22C55E">How do you help engineers move faster without making a mess?</callout>As it turns out, the same instincts for making great dev-x also work for coding agents. The principles transfer almost perfectly — and that realization shaped how we built our engineering culture from day one. Over time I've distilled it down to four things I keep coming back to. These aren't abstract ideals; they're the concrete decisions we made about how our codebase is structured and how our team operates inside it. <collapsible-card data-icon="layers" data-title="1. Monorepos with trunk-based development" data-default-collapsed="true">One codebase, one source of truth. When everything lives together, context is a <code spellcheck="false" style="white-space: pre-wrap;">grep</code> away — for humans and agents alike. Trunk-based development keeps the main branch always shippable and eliminates the long-lived branch tax that slows teams down. There's no "integration hell" because integration is continuous.</collapsible-card> <collapsible-card data-icon="shield" data-title="2. Pattern-match and make it type-safe" data-status-color="#8B5CF6" data-default-collapsed="true">Don't let engineers guess how to do something. Establish standard patterns, enforce them with types, and let automated tests scream when someone goes off-script. Agents are pattern-matching machines — give them good patterns to match. The goal is a codebase where the right way to do something is also the easiest way to do it.</collapsible-card> <collapsible-card data-icon="zap" data-title="3. Build structures that make code easy to delete" data-default-collapsed="true">Easy-to-delete code isn't fragile — it's the opposite. Small, well-bounded, replaceable modules are what enable true vibe coding: ship a feature fast for validation, and if it doesn't work, rip it out cleanly. No scar tissue, no six-month refactor to undo a bad bet. The ability to move fast depends entirely on your ability to reverse course.</collapsible-card> <collapsible-card data-icon="rocket" data-title="4. Implement assuming deprecation" data-status-color="#EF4444" data-default-collapsed="true">Nobody knows what tomorrow looks like — especially in AI, where model providers change constantly. Build every integration with a seam. Assume the thing you're wrapping today will be swapped out next quarter. It's the difference between a codebase that ages gracefully and one that becomes a liability the moment the ecosystem moves.</collapsible-card> We started with these four principles back in September of last year, and they gave us a strong foundation. But as the product got more complex, I realized principles alone weren't enough to sustain our velocity. Rules on paper don't ship features — people do. Even a perfectly structured codebase can grind to a halt if the team isn't aligned on why it's structured that way. Which is why the real unlock wasn't just the code structure. It was the culture we built around it. <h2 id='9686dac4-71e2-4362-a95a-21c46e269873'>Culture</h2>Speed is a gift and a curse. When you're shipping fast, a single day lost to misalignment or team friction isn't just frustrating — it's a real blow to momentum. As the cost of coding has come crashing down (especially with the systems we've built), the bottleneck has shifted. The hard problem was no longer writing code; it became coordination. That realization pushed us toward a culture built on two pillars: deep alignment and compounding decisions. We needed a way to ensure that the low-level choices we made every day would stack up into something durable over time — not drift into technical and organizational disarray. <h4 id='187ca216-fc1a-4f83-944a-2e76d9e546d8'>Docs</h4>The answer for us became a doc-driven development team. No major feature ships without a clean RFC attached to it. It sounds like overhead, but in practice it's been one of the highest-leverage investments we've made. The positive externalities have been significant: <collapsible-card data-icon="lightbulb" data-title="Deeper thinking before building" data-default-collapsed="true">Writing forces clarity. Teams that write RFCs catch edge cases, surface disagreements, and arrive at implementation with far more confidence.</collapsible-card> <collapsible-card data-icon="users" data-title="A shared workspace for humans and agents" data-default-collapsed="true">Documents give both people and AI a concrete, structured place to collaborate, iterate, and align.</collapsible-card> <collapsible-card data-icon="clipboard" data-title="A system of record for past decisions" data-default-collapsed="true">When someone asks "why did we build it this way?", the answer is always findable.</collapsible-card> I think culture, at its core, is just the set of habits a team repeats under pressure. Ours is: write it down, align early, and let the decisions compound. That foundation is what makes everything that comes next possible. We used to live in Google Docs like everyone else. That changed in November, when our own platform became stable enough to migrate fully into it. Now our entire planning and RFC process runs through ProductNow — and honestly, there's no going back for us. <flow-diagram data-nodes="[{"data":{"label":"Plan in Repo"},"id":"1","position":{"x":-10,"y":101.25},"type":"input"},{"data":{"label":"MCP Push"},"id":"2","position":{"x":200,"y":100},"type":"default"},{"data":{"label":"ProductNow"},"id":"pn","position":{"x":200,"y":200},"type":"default"},{"data":{"label":"RFC Template"},"id":"3","position":{"x":200,"y":300},"type":"default"},{"data":{"label":"Rich Canvas"},"id":"4","position":{"x":200,"y":400},"type":"default"},{"data":{"label":"Team lead's agent reviews"},"id":"5","position":{"x":200,"y":500},"type":"default"},{"data":{"label":"Team Iteration"},"id":"6","position":{"x":200,"y":600},"type":"default"},{"data":{"label":"Team lead (human) reviews"},"id":"7","position":{"x":200,"y":700},"type":"default"},{"data":{"label":"MCP Pull from ProductNow"},"id":"8","position":{"x":200,"y":800},"type":"default"},{"data":{"label":"Implementation"},"id":"9","position":{"x":200,"y":900},"type":"default"},{"data":{"label":"On Drift from RFC"},"id":"10","position":{"x":446,"y":104},"type":"default"}]" data-edges="[{"id":"e1-2","source":"1","target":"2","type":"smoothstep"},{"id":"e2-pn","source":"2","target":"pn","type":"smoothstep"},{"id":"epn-3","source":"pn","target":"3","type":"smoothstep"},{"id":"e3-4","source":"3","target":"4","type":"smoothstep"},{"id":"e4-5","source":"4","target":"5","type":"smoothstep"},{"id":"e5-6","source":"5","target":"6","type":"smoothstep"},{"animated":true,"id":"e6-self","label":"iterate","source":"6","target":"6","type":"smoothstep"},{"id":"e6-7","source":"6","target":"7","type":"smoothstep"},{"id":"e7-8","source":"7","target":"8","type":"smoothstep"},{"id":"e8-9","source":"8","target":"9","type":"smoothstep"},{"id":"e9-10","source":"9","target":"10","type":"smoothstep"},{"animated":true,"id":"e10-2","label":"drift","source":"10","target":"2","type":"smoothstep"}]" data-height="420"></flow-diagram> <ol><li value="1" class="LexicalTextEditor-module-scss-module__vIcBXa__listItem">Plan in the repo — The team plans directly in the codebase, using agents to compile relevant context and information.</li><li value="2" class="LexicalTextEditor-module-scss-module__vIcBXa__listItem">MCP push — That plan gets pushed up to ProductNow via MCP.</li><li value="3" class="LexicalTextEditor-module-scss-module__vIcBXa__listItem">RFC template — ProductNow converts it into our standard RFC format automatically.</li><li value="4" class="LexicalTextEditor-module-scss-module__vIcBXa__listItem">Rich canvas — The canvas lets us express complex ideas in far more information-dense ways than plain markdown ever could — diagrams, charts, code comparison, structured tables, all of it.</li><li value="5" class="LexicalTextEditor-module-scss-module__vIcBXa__listItem">Agent review — Team lead's agent reviews the doc first and leaves an initial round of comments (prechews the document).</li><li value="6" class="LexicalTextEditor-module-scss-module__vIcBXa__listItem">Team iteration — The team works through the feedback, iterating until the doc is ready for approval.</li><li value="7" class="LexicalTextEditor-module-scss-module__vIcBXa__listItem">Final stamp — Team lead (human) does a final review and gives the green light.</li><li value="8" class="LexicalTextEditor-module-scss-module__vIcBXa__listItem">MCP pull — The approved doc gets pulled back down via MCP and implementation begins.</li><li value="9" class="LexicalTextEditor-module-scss-module__vIcBXa__listItem">Stay in sync — If implementation drifts from the plan, we MCP the delta back up so the doc always reflects reality.</li></ol> The result is a tight loop between code and documentation — one that keeps the whole team aligned without the usual overhead. It's keenly focused on human download time. It's a workflow we've come to rely on, and it shapes a lot of how we think about what comes next. <h4 id='fbf22232-b520-42b6-b6be-01ec53beaf54'>MTS and oncall</h4>This has let us do something a little out there: in theory, we felt there’s enough context that you can tag the ProductNow agent in Slack and understand why something works a certain way. That means the engineering decision log is accessible to everyone. Paired with coding agents for debugging and a solid runbook, we thought: <callout icon="megaphone" color="#F59E0B">Anyone should be able to go oncall</callout>So that’s what we’ve tried. Everyone on the team is a member of technical staff in earnest. We don’t split people into infra, ML, backend, frontend, design, or creative tech. Everyone is MTS. Everyone can work across the stack. Everyone can gather context from anywhere. And everyone is oncall. The ramifications of that are still unfolding. Ask me again in a few months and I’ll tell you what we’ve learned. For now, it’s been a wild experiment — and so far, so good. <h4 id='5c56f6c9-2cc1-4a33-93f3-f3e6efe4a1aa'>Planning</h4>There's one more lesson we've learned the hard way: if we let Claude and friends do all the thinking, the planning, and the implementation, we're left with the crappiest job of all — reviewing. And worse, we haven't spent enough time stewing on the problems to deeply understand the proposed solution. The result? <callout icon="alert-triangle" color="#EF4444">We don't guide the agents well, the outcome for the platform suffers, and frankly, it's exhausting.</callout>The fix isn't to use AI less — it's to stay in the driver's seat. The engineers who get the most out of these tools are the ones who've already done the hard thinking: they understand the problem deeply, they have a point of view on the solution, and they use AI to accelerate execution — not replace judgment. And this matters even more when you zoom out and think about what our clients are actually buying. They're not buying lines of code. They're not even buying features. They're buying outcomes. They want a problem solved. That reframing changes everything about how we plan. When you're optimizing for outcomes rather than output, the quality of your thinking before you write a single line of code becomes the most important variable in the equation. Deep planning isn't overhead; it's the work. At Palantir, Shyam had a saying: culture eats strategy for breakfast. And I believe that. And at its core, I think this whole thing has to be fun — because if it isn't, this becomes a truly exhausting job, which leads to much worse outcomes across the board. That's the real north star for how we work with AI: keep the craft alive, keep the thinking human, and make sure the work still feels like ours. Which brings us to one of our new rules at ProductNow: agents don't do the thinking or the planning. You can use them to brainstorm. But when it comes time to write the RFC, those are your thoughts. Your ideas. The agent didn't form that opinion; you did. And that distinction matters more than it might seem. The results have been striking. Keeping the thinking human is unlocking something amazing: <collapsible-card data-icon="zap" data-title="The team is more motivated than ever" data-default-collapsed="true">They get to focus on the fun part: the actual thinking.</collapsible-card> <collapsible-card data-icon="target" data-title="Outcomes are better" data-default-collapsed="true">We spend more time sitting with ideas, which means better ideas.</collapsible-card> <collapsible-card data-icon="rocket" data-title="We paradoxically go faster" data-default-collapsed="true">Features are more thoroughly thought through upfront, so they ship with fewer issues.</collapsible-card> It turns out that protecting the human part of the process — the messy, effortful, creative work of forming an opinion — is what makes everything downstream better. <h2 id='27e7cac5-253b-46c0-bb41-9a6f3ae1879f'>Looking ahead - the future</h2>Software development has never been more exciting. We've never had so much capability before — the tools, the abstractions, the AI assistance. Software as a concept seems to be on its way to being generally solved. Imagine what we can build next with it! So above all else, I think this should be fun. We're living in exciting times; there's a whole new frontier of exciting problems coming. At ProductNow, we believe human time is precious — and it should be spent on the things that matter most: the creative, the meaningful, the fun. That's the north star guiding everything we build. A fundamentally different way of working — one where AI handles the repetitive, the mechanical, and the tedious, so we can focus on the decisions humans should make. The roadmap ahead is ambitious. Imagine simulated agentic meetings where AI participants surface conflicts and align stakeholders before a single human joins the call. Or voice agents that run your doc reviews, reading through feedback and synthesizing it into actionable next steps. Or systems that can automatically negotiate disagreements between team members by surfacing shared context and common ground. And so much more. <callout icon="rocket" color="#8B5CF6">Our vision: foster human ↔ AI collaboration so effectively that shipping products everyone loves becomes the natural outcome.</callout> And here's the take I'll end on: I don't think the future belongs to small teams. I don't think the future belongs to the most capable individuals. <callout icon="flag" color="#F59E0B">I think it belongs to large teams that figure out how to coordinate and collaborate super effectively.</callout>The bottleneck won't be capability — it'll be coordination. The teams that crack that will build things we can't yet imagine.

Embed this documentUse this link to embed the document on an external website. It opens a stripped-down view with just the document content.