Tag: product roadmapping and sprint planning

Go Totally Asynchronous: Inside Sidharth Kakkar’s Remote, Autonomous Culture That Scales

I’ve spent years leading product teams across global B2B SaaS, and few topics spark more debate than building a remote team that operates totally asynchronously. Recently, I revisited the playbook of Sidharth Kakkar, founder and CEO of Subscript, a subscription intelligence platform that empowers B2B SaaS leaders to better understand their revenue. (Read more about the company in this Techcrunch article.)

Previously, he was the founder, CEO of Freckle, an education platform that grew to serve 10 million students and was acquired by Renaissance Learning in 2019. As a repeat founder, Sidharth picked up a ton of valuable lessons, particularly when it comes to company culture and management.

Right from the start, he knew he wanted to build Subscript to be global, distributed, and asynchronous. That’s why there are no internal company meetings. Everyone also operates autonomously, deciding what to work on for themselves.

In this analysis, I dive into both the philosophy behind this unique approach and the nitty gritty details of how exactly it works in practice. I’ll unpack how to share company updates asynchronously every week; advice on how to approach goal-setting and performance feedback while minimizing micromanagement; tips for improving transparency and documentation, plus details on Subscript’s running product/market fit journal; thoughts on how to assess asynchronous communication skills when hiring; and how this culture impacts a founder’s role and schedule.

On weekly updates, asynchronous communication shines when it is consistent, structured, and outcomes-focused. I recommend a lightweight cadence that combines a written executive summary, links to artifacts (roadmaps, PRDs, dashboards), and optional short Looms for rich context. Tie each update to outcomes vs output OKRs so teams self-calibrate without meetings, and make updates searchable so new hires can ramp themselves with a clear trail of decisions and tradeoffs.

For goal-setting and performance feedback, autonomy and clarity must coexist. Define clear success metrics upfront, timebox discovery, and use product roadmapping and sprint planning rituals that emphasize measurable customer outcomes over task completion. Replace micromanagement with transparent expectation docs, written performance narratives, and asynchronous 360 feedback—so individuals know what good looks like and can course-correct without waiting for a meeting.

Transparency and documentation are the backbone of a remote, autonomous culture. Centralize decisions in a single source of truth, standardize decision records, and maintain a living discovery log alongside Subscript’s running product/market fit journal. This practice compresses feedback loops, preserves institutional memory, and accelerates product discovery by making assumptions, experiments, and results easy to consume across time zones.

When hiring, I prioritize asynchronous communication skills as first-class selection criteria. Use written work samples, time-boxed take-home prompts, and collaborative docs to evaluate clarity, rigor, and empathy in writing. Look for signal such as strong structuring, crisp problem statements, thoughtful tradeoffs, and proactive documentation of risks and unknowns—capabilities that predict success on distributed teams.

This culture fundamentally reshapes a founder’s role and schedule. With deep work protected and status noise automated, leaders can spend more time on strategy, customer conversations, and coaching. Decision latency drops because context is captured in writing, and the organization scales through principles rather than approvals—exactly what you want in a high-trust, high-leverage product operating system.

There’s tons of food for thought in here, whether you’re a founder thinking about shaping your company culture, or a manager looking for some fresh ideas.

Inspired by this post on First Round.

October 21, 2025
Operations vs Algorithms: How I Scale Startups with Data Science, Team Design, and Pre-Mortems

I recently revisited one of the most practical conversations I’ve had about scaling: insights from Ian Wong, co-founder and CTO of Opendoor. Before founding Opendoor, Ian was Square’s first data scientist, where he developed machine learning models and infrastructure for fraud detection. That trajectory—building from operational muscle to algorithmic advantage—maps closely to how I’ve led product and data investments in fast-growing environments.

As Ian puts it, in the early innings it might make sense for your startup to be operations heavy. But as you start to scale, data science becomes a critical component for running a business with longevity in mind. This mirrors my experience: hands-on operations create the learning loops you need early, while data science turns those learnings into scalable systems, better forecasts, and tighter risk controls.

We dive into how both Square and Opendoor approached this transition. The progression is instructive—start with pragmatic operational workflows to validate demand and unit economics, then shift toward machine learning and automation once the process is stable, the data pipeline is trustworthy, and the cost of manual work begins to drag margins and responsiveness.

Along those lines, we discuss some of the early considerations for your fledgling data science team, including the type of folks to hire for the early team, like whether to look for generalists or specialists, and how to set up your interview loops. In my playbook, I bias toward T-shaped generalists first—people who can partner with product, analytics, and engineering—then layer in specialists (ML ops, causal inference, experimentation) as complexity grows. For interview loops, I ensure we evaluate for problem framing, data intuition, model-to-product translation, and stakeholder communication—not just model accuracy.

Ian also dives into his lessons on structuring the data science function so that it’s deeply integrated with the rest of the technical org. I’ve found embedded pods work best early—data scientists sit with product teams to accelerate discovery, instrumentation, and iteration—paired with a light central platform group to standardize data quality, experimentation frameworks, and model deployment practices.

Next, we dive into some of his biggest lessons as a first-time founder and CTO, including his practice with Opendoor’s leadership team of doing pre-mortems to predict why something might not work. He also encourages founders to run through a bi-yearly exercise of re-writing their job rec. I’ve seen both rituals raise the bar: pre-mortems surface hidden risks before launch, and re-writing the job rec forces leaders to shed responsibilities, prevent role drift, and keep the org structured for the next stage—not the last one.

Practically, my guidance to founders and product leaders is straightforward: define the decisions data science will improve (pricing, risk, routing, personalization), instrument for leading indicators, and ruthlessly prioritize the smallest models that deliver outsized business value. Avoid premature optimization—let operations teach you where the algorithm belongs. Use clear success metrics to track outcomes, not just output, and revisit them as your market and product expand.

Finally, remember that the goal isn’t to replace operations—it’s to make operations smarter. Pair human judgment with machine learning in the workflows that matter most, invest in trustworthy data foundations, and build hiring and interview loops that reward interdisciplinary problem solvers. That’s how you turn early operational grit into durable, data-driven advantage.

October 21, 2025
Airtable’s Journey to Product-Market Fit: Hard-Won Lessons on Building Horizontal Products

I recently dove deep with Andrew Ofstad, co-founder of Airtable, to unpack Airtable’s path to product-market fit and the realities of building a truly horizontal product. As a product leader, I’m always looking for patterns that translate across teams and stages — and this conversation offered a wealth of practical insights for founders and product managers alike.
We started with first principles: how the founders came together, their vision for the product, and what the initial prototypes looked like. That early narrative matters — it anchors positioning, keeps scope disciplined, and ensures your earliest builds reflect the core value proposition rather than a laundry list of features.
From there, we stepped through Airtable’s alpha, beta, and launch timelines, as well as their early traction. I pay close attention to these milestones because they reveal the learning cadence: how quickly teams validated hypotheses, which signals they treated as leading indicators, and how they balanced qualitative pull with quantitative adoption during product discovery.
We also explored the challenges of creating a horizontal product that can do many things, including identifying initial use cases and figuring out how to describe what they were building. In my experience, the key is to land a small set of canonical use cases, articulate crisp jobs-to-be-done, and build narrative clarity around the “why now.” Without this, even great products struggle to convert curiosity into active usage.
On commercialization, we dug into how to approach pricing and competition, as well as their early go-to-market strategy. For products with broad applicability, I’ve found that founder-led GTM is essential early on — it shortens the learning loop and informs SaaS pricing and packaging. Start with simple, customer-aligned tiers, validate willingness to pay against clear outcomes, and keep positioning focused on value, not feature parity.
We then looked ahead to what the next 3 years will look like for Airtable, and how they’ve navigated scaling while staying true to their vision. Scaling a horizontal product requires tight product roadmapping and sprint planning, strong messaging discipline, and an unwavering commitment to the core value — all while layering ecosystem leverage, templates, and community to accelerate adoption without diluting the product’s identity.
Whether you’re a founder validating your own idea, or a product leader looking for growth advice, there are tons of tactics here that go much deeper than the typical founding stories you hear. My takeaway: great horizontal products find product-market fit by starting narrow in use case, obsessing over teachability, and letting customer outcomes pull the roadmap forward.

Inspired by this post on First Round.

October 21, 2025
Inside Figma’s 5-Phase Community-Led Growth Playbook to Ignite Organic GTM

When I study companies that turn product-market fit into durable, compounding momentum, Figma stands out. In this breakdown, I walk through Figma’s five phases of community-led growth and share how I’d apply each step to build an organic growth engine. My lens is product management leadership paired with pragmatic GTM thinking, so the emphasis is on what to do, when to do it, and why it works.

Phase 1 centers on the lessons from years in stealth mode — specifically, how to start planting the seeds for a community when you don’t have a fully-formed product. I focus on the inflection point to emerge from stealth, what signals matter, and how to use early feedback loops for product discovery without over-rotating on feature requests. Quietly building is necessary; quietly engaging is essential.

In this early phase, my playbook prioritizes rigorous product discovery, crisp problem narratives, and a cadence that makes learning visible. I invest in relationship-building with credible early adopters, share prototypes thoughtfully, and shape outcomes over output through disciplined product roadmapping and sprint planning. The goal is to design a community that feels invited into the creative process while preserving the integrity of your vision.

Phase 2 is all about the launch playbook — from taking over design Twitter, to marketing to folks who tend to bristle at traditional SaaS marketing. Here, founder-led GTM matters. I pair zero to one B2B marketing with specific audience rituals, leaning into channels where the product can be experienced, not just described. The message avoids enterprise jargon and instead showcases feel, speed, and collaboration, so the community can instantly “get it.”

Phase 3 shifts the focus to activation via community gravity. The goal is to get folks to try the product, even if they weren’t going to switch over right away to designing in Figma full-time. This is where I formalize an evangelist strategy — spotlighting workflows, templates, and stories that reduce the cost of the first session. I think about developer evangelism patterns applied to designers: celebrate makers, distribute small wins widely, and build momentum with authentic, peer-to-peer proof.

The final two phases connect passionate individual users to an enterprise strategy. They didn’t layer in a sales team until four years after the product launched, and didn’t add a paid product tier until another two years after that. Those choices underscore a disciplined sequencing of PLG with a sales overlay — land with love, expand with proof, monetize with timing.

In practice, this means evolving from bottoms-up adoption to clear value narratives for team and enterprise tiers, while tuning SaaS pricing and packaging to customer maturity. I optimize the handoff from product-led signals to sales motions, align success metrics to outcomes (not just usage), and enable procurement-friendly paths without dulling what made the product magical. That’s the GTM trade-off: protect the community engine while scaling into enterprise.

If you’re building your own community-led growth engine, these phases offer a durable blueprint: learn in stealth, launch where your audience lives, activate with authentic evangelism, and scale with a thoughtful enterprise bridge. Done well, this approach compounds — it strengthens product-market fit, accelerates zero to one B2B marketing, and sets the stage for sustainable growth without overreliance on paid channels.

October 21, 2025
From Roadmaps to Sprints: Proven Tactics to Ship Software at Scale Without Chaos

I recently sat down with Snir Kodesh, Head of Engineering at Retool, a development platform for building custom business tools. Before joining Retool, he spent six years as a Senior Director of Engineering at Lyft. Coming from my vantage point leading product at HighLevel, I was eager to compare notes on what it really takes to ship software at scale without losing clarity, customer focus, or team morale.

We dug into the biggest differences between leading engineering teams for a consumer product versus an enterprise platform — and the patterns that hold true across both. Consumer surfaces demand rapid iteration loops and relentless UX polish; enterprise platforms demand configurability, security, reliability, and stakeholder alignment across buyers and users. In my experience, the constant across both worlds is crisp product management leadership: clear problem definition, tight feedback loops, and unambiguous ownership.

We pulled back the curtain on the software development cycle, starting with setting the product roadmap while balancing a diverse set of customer needs. On roadmapping, I ensure we explicitly identify who’s in the room to represent product, engineering and design, as well as customer-facing teams like support and solutions. The most effective sessions make trade-offs visible: we quantify impact, risk, and effort; we surface dependencies; and we align on outcomes before timelines. The result is not just a list of features, but a sequenced narrative that earns the right to build.

From there, we discussed how engineering takes that product roadmap and turns it into a concrete plan of action using the “try, do, consider” framework. I’ve found this framing incredibly practical: “try” creates space for low-risk experiments, “do” commits to high-confidence work, and “consider” tracks explorations that need more discovery. When sprint planning inherits this taxonomy, teams retain momentum without overcommitting — and leaders get a transparent view into where learning versus delivery is happening.

He makes the case for leaning on QBRs instead of OKRs. I agree that quarterly business reviews calibrate teams on real outcomes, not vanity metrics, and they naturally force prioritization around customer value. When we do use OKRs, we emphasize outcomes vs output OKRs so teams aren’t incentivized to ship volume over impact. In practice, QBRs keep us honest: what shipped, what moved the needle, and what needs to change next quarter.

We also tackled why scope creep gets a bad rap. In my experience, what’s labeled as “scope creep” is often legitimate learning uncovered through product discovery. The key is disciplined change management: time-box discovery, explicitly re-baseline when new information emerges, and separate must-haves from nice-to-haves. When done well, this turns surprises into strategic clarity rather than delivery risk.

On estimation, we shared practical tactics for getting better at estimating how long a feature will actually take to complete. I lean on reference-class forecasting (compare to similar past work), risk burndown charts, explicit buffers for integration and QA, and a habit of capturing deltas between estimate and actuals. Over time, this creates a trustworthy velocity signal and sharpens intuition across both product and engineering.

Translating the roadmap to sprint planning is where execution quality shows. We align on definitions of ready and done, maintain code review SLAs, budget a percentage for tech debt, and instrument everything so we can spot drift early. The “try, do, consider” framework maps cleanly to backlog hygiene, keeping discovery visible without derailing delivery. This is how we sustain speed and quality at scale.

Finally, we zoomed out to essential advice for engineering leaders — especially folks scaling quickly from leading a small team to a much bigger one. Shift from direct control to leverage: clarify decision rights, invest in Staff+ ICs, and scale communication through operating cadences, decision logs, and crisp narratives. Pair autonomy with accountability using QBRs, and keep product discovery tight to preserve customer empathy as you add layers. The goal is the same at ten people or a thousand: ship valuable software predictably, learn fast, and keep the team energized.

If you’re navigating the leap from product roadmapping to sprint planning, these patterns are battle-tested. Anchor on outcomes, use the “try, do, consider” lens to manage ambiguity, and treat scope as a living artifact informed by discovery. With the right rituals and metrics, you can ship software at scale — without chaos.

October 21, 2025