Full-day workshops.
Build frameworks that last.
Not a one-time event. A system your team uses quarter after quarter — for planning, decisions, roadmaps, and performance.
Pick Core Workshops when
Systemic issue
Not one stuck decision — a pattern. Planning breaks down every quarter. Roadmaps don’t hold. The team’s operating system needs a reset.
Want frameworks that compound
Quick fixes won’t cut it. You need something your team internalises and uses on their own, long after the workshop ends.
Ready for transformation
The team is willing to invest a full day. They want real change, not a checkbox exercise. They’re ready to do the work.
Investment: &rupee;1.5L–2L
Full-day commitment. 4–8 hours of deep work. You leave with frameworks, action plans, and a 30-day follow-up call.
How to choose which workshop
Click to jump to the workshop details.
The Workshops
7 workshops. Each transforms a different operating challenge. All build frameworks your team keeps.
The Innovation Engine
Stop pushing innovation. Build the system that makes it happen.
‘We need to innovate more.’ Third all-hands this year with that message.
Last Tuesday someone posted an idea in Slack. Three thumbs-up. Nobody did anything. Idea died by Friday.
You tried 10% time. They used it to catch up on tickets. You tried innovation Fridays. Sprint was behind so nobody showed up.
Not a motivation problem. A system problem.
What This Looks Like
Payments startup, just raised Series B. Team grew from 8 to 18. CTO keeps talking about ‘innovation culture’ in standups. Engineers keep building features.
Problem wasn’t motivation. It was: When does innovation actually happen? Where do ideas go? If it fails, does it hurt my review?
One session: Team designed their Innovation Engine. First Thursday afternoon monthly is protected innovation time. Ideas go in #experiments channel. Team votes Mondays which to try. Failed experiments get documented with ‘What we learned.’
Result: Junior engineer pitched a risky caching change. Cut API response time 40%. Three months later: four experiments shipped, three in progress. Team runs the weekly vote themselves.
How It Works
Everyone writes down why innovation doesn’t work here. Anonymous cards. On the wall. Then we attack them like bugs. ‘We don’t have time’—let’s measure. ‘Ideas go nowhere’—because there’s no system.
Then we prove it’s doable: a real problem, ridiculous constraints, eight minutes, no code. Forces sideways thinking. They solve it every time.
Teams build competing versions of the Engine in parallel. One designs rhythm and pipeline. Other designs safety net and ownership. Merge. Stress-test. Half the room breaks it, half fixes the holes.
Key insight: Innovation isn’t creativity. It’s a system that moves creativity to production consistently.
What You Walk Out With
- Innovation Engine. Rhythm locked. Pipeline clear. Safety net built. Ownership rotating.
- 3–4 experiments committed. Owners assigned. Testable in one week.
- Check-ins at 30 and 90 days. We fix what breaks.
- You’ll know it worked when someone posts an idea in #experiments without being asked. Two people volunteer to help. Nobody prompted that.
Pick This If
- Leadership keeps pushing ‘innovation culture’ but team has no system
- Domain moves fast (AI, fintech) and you need continuous experimentation
- Team has stopped suggesting things because “nothing happens anyway”
- You’re tired of being the one always pushing for innovation
Not Innovation Sprint
- Sprint = two days, one problem, prototype it, done
- Engine = one day, build the system that runs quarterly forever
Three months in: Weekly innovation standup runs itself. Junior engineer just pitched something bold. Your role? Staying out of the way.
Quarterly Planning
Plan the quarter + build the framework you’ll reuse forever.
Last quarter’s planning took four hours. You made a deck. Forty-three slides. Looked great.
Week two, customer escalation lands. Sales wants urgent feature. Engineering’s prioritising tech debt. Nobody checks the deck. You make a call.
Week six, different customer. Different urgent thing. Deck still sits in Drive. 12 views total.
You spent four hours planning. Those priorities guided exactly zero decisions.
What This Looks Like
SaaS company. B2B product. PM team does quarterly planning religiously. Every quarter, mid-quarter requests blow up the plan. Fourth quarter in a row.
Real issue: No framework for HOW they chose those priorities. So every new request becomes a fresh debate.
One session: Built prioritisation framework together. Customer impact: 35%. Strategic alignment: 30%. Technical complexity: 25%. Revenue potential: 10%. Weighted scoring. Applied to every competing request. Chose top 5 initiatives with documented rationale.
Result: Sales brings urgent feature request. PM scores it—62 points. Threshold is 70. Says no with specific rationale. First time that happened without a week of debate. All 5 initiatives shipped. First time in a year.
How It Works
Morning: last quarter retrospective. What shipped? What didn’t? Why? If you committed to 8 things and finished 3, we don’t say ‘you failed 5.’ We say ‘we overcommit by 2.5x, let’s fix that.’
Brain dump everything competing for next quarter. Customer requests. Sales escalations. Tech debt. Strategic bets. All on the wall.
Afternoon: build YOUR criteria. Not generic impact/effort matrix. Your specific factors for this team at this stage. Weight them. Can’t all be 25%—force real choices.
Score everything. Silent first (prevents anchoring). Discuss outliers. Converge on top priorities. Last hour: extract the reusable template.
What You Walk Out With
- This quarter’s priorities. Clear. Documented. Everyone knows WHY, not just WHAT.
- The framework. Criteria. Weights. Process. Templated. Reusable every quarter.
- When urgent request lands, team scores it. Decides themselves. You’re not the decision bottleneck.
- Compounding effect: Q1: build it (full day). Q2: apply it (3 hours). Q3: team runs it (90 minutes).
Pick This If
- You do planning but it doesn’t stick past week 3
- Mid-quarter requests constantly derail the plan
- Want framework that compounds, not a one-time session
- Multiple teams with tangled dependencies
Different from Priority Reset
- Priority Reset = 2.5 hours, this quarter, make the call now
- Quarterly Planning = full day, build framework once, use forever
Six months later: New urgent request lands. Team evaluates using the framework. Decides without escalating. You find out after they already said no.
Product Roadmap Workshop
Build 6-month roadmap + the logic for how you decide what ships next.
Roadmap meeting. Week three. Same debate.
Product wants mobile app—‘customers keep asking.’ Engineering wants API redesign—‘tech debt is killing us.’ Sales wants enterprise SSO—‘three deals blocked.’ Leadership wants AI features—‘board keeps asking.’
All valid. All incompatible. You’ve been in this room for 6 hours across 3 meetings. Nobody’s budging.
There’s no shared way to decide. So the loudest argument wins.
What This Looks Like
SaaS product. Mid-stage. Roadmap planning had been circling for 7 weeks. Product and engineering couldn’t align. CEO getting frustrated—‘just decide already.’
Real problem: everyone evaluating features through different lenses. Product thinking customer pain. Engineering thinking technical sustainability. Sales thinking closed deals. All using different mental models.
One session: Built evaluation framework together. Customer demand: 25%. Pain severity: 20%. Strategic fit: 25%. Technical effort: 20%. Revenue impact: 10%. Applied to 23 competing features.
Result: Converged on 6-month roadmap in one afternoon. Everyone bought in because they built the logic together. Next week, customer asked for custom reporting. PM scored it—58 points. Threshold 65. Said no with clear rationale. Customer accepted it.
How It Works
Everything goes on the wall. All feature requests. All customer asks. All ‘we really should fix this’ items. All strategic bets. Nothing filtered yet. Just visible.
Then: what factors actually matter for THIS product at THIS stage? Early product needs different criteria than mature product. B2B enterprise different than consumer. Team defines their factors.
Weight them. Force choices. Can’t all be important. Score everything. Silent first so nobody anchors. Then discuss the big gaps—where Product scored something 9 and Engineering scored it 3. Why? Surface the assumptions.
Document the why. Not just ‘feature X made roadmap.’ WHY X made it and Y didn’t. When next customer escalates Z, team evaluates using same framework.
What You Walk Out With
- 6-month roadmap. Sequenced. Three lanes: Committed, Exploring, Parking lot. Everyone aligned on why.
- Scoring framework. Criteria. Weights. Process. Reusable for every future request.
- When Sales escalates something, team scores it objectively. Makes threshold or doesn’t. Decision based on data, not politics.
- 30-day follow-up call to check roadmap health and refine the process.
Pick This If
- Roadmap debates circle, stakeholders can’t align
- Different teams prioritising with different mental models
- Customer requests and sales escalations disrupting roadmap
- Roadmap reviews take 2–3 weeks per cycle
Different from Quarterly Planning
- Quarterly Planning = all work (initiatives, ops, tech debt)
- Product Roadmap = specifically feature prioritisation
Next roadmap cycle: Team applies framework. One meeting. Two hours. Decision made. Debate collapsed from 3 weeks to 120 minutes.
Team Operating System
Map how your team actually thinks. Redesign how you work to match.
Friday afternoon. Your PM and Tech Lead are in your office. Again. Third time this week.
PM: ‘He asks a million questions. We’ll never ship anything.’ Tech Lead: ‘She gives me vague requirements. I can’t build from this.’
You like both of them. They’re both good at their jobs. But together? Constant friction.
Not a personality clash. Your process is designed for neither of them.
What This Looks Like
Series B startup. PM and Tech Lead clashing for 7 months. Every handoff tense. Sprint planning consistently 3 hours. Manager spending 10+ hours per week mediating.
PM thinks three moves ahead. Sees big picture first, fills in details later. Tech Lead maps all edge cases before deciding. Needs time to think through what could break. Both essential. Both doing their jobs well. But your handoff process? Designed for neither.
Workshop fixed it. PM now provides strategic context AND detailed requirements together. Tech Lead gets 24-hour pre-read. Planning starts with 15-minute silent analysis time, then structured discussion with decision checkpoints every 20 minutes.
Result: Sprint planning went from 3 hours to 45 minutes. Handoffs smooth. They’re collaborating now instead of fighting.
How It Works
We start by understanding how each person processes information. Not ‘personality types’—thinking patterns. Who needs data first. Who needs big picture. Who thinks out loud vs needs quiet time.
Then we find where friction actually shows up. Handoffs? Planning? Decisions? Map the specific moments where mismatch creates conflict.
Redesign those workflows. Requirements doc includes both: strategic context AND edge case handling. Pre-read time AND live discussion. Accommodates both, favours neither.
Key difference: We don’t just document norms. We design systems that match how people are actually wired.
What You Walk Out With
- Operating manual. How THIS team collaborates. Handoffs, decisions, meetings, feedback. Customised for how these specific people think.
- Redesigned workflows for whatever creates most friction. Usually sprint planning, handoffs, decision-making.
- ‘How We Work’ guide. One page. New person joins? Reads it. Gets it.
- 30-day follow-up call to check adoption and adjust what’s not working.
Pick This If
- Multiple people clashing (not just one pair)
- Friction across workflows—planning, handoffs, decisions
- Team grew fast (went from 5 to 15 people)
- Sprint planning consistently takes 2+ hours
Different from Team Friction Diagnostic
- Friction Diagnostic = 2 hours, two specific people, diagnose the clash
- Operating System = 4–5 hours, whole team, redesign workflows
Thirty days later: Sprint planning 40% shorter. Two people who couldn’t collaborate are making joint decisions. You spend zero hours mediating.
Team Kickoff Workshop
Launch new teams right. Skip the 90 days of painful figuring-it-out.
New team. You’re leading it. First sprint starts Monday. Half are transfers, half are new hires been here 2 weeks.
Nobody knows how decisions get made. Who owns what. When to sync vs Slack. How to disagree without it getting weird.
Most teams spend the first 3 months stumbling. Unclear ownership. Meetings that run long. Velocity 40% below where it should be.
First 30 days set the patterns. Start wrong, you fix it for 6 months.
What This Looks Like
Product team forming to rebuild core product. Twelve people. Mix of old product team, engineering, three new hires. Ship v2 in 6 months.
First sprint: chaos. Standup ran 45 minutes. Two people worked on same thing. Planning hit 4 hours. Velocity at 40% of target.
Ran the kickoff. Built the charter together. Mission: rebuild for performance and reliability, not just feature parity. Decisions at lowest level possible. Default async, sync only when needed.
Result: First sprint after workshop—velocity at expected level. Sprint 4: 20% above target. New person joined week 5, read the charter, productive same day.
How It Works
We start with mission. What are we actually here to do? Not the corporate answer—the real one. What does success look like in 6 months? What are we explicitly NOT doing?
Then working styles. Who needs morning quiet time? Who processes by talking vs thinking first? Who’s energised by quick decisions vs needs time to analyse? Get it visible so people understand each other.
Then the hard part: How do we actually work? When do we meet vs Slack? How do we make decisions—consensus, consult, or just decide? How do we handle conflict?
Not theoretical. Test against real scenarios. ‘Sales escalates urgent request mid-sprint—what do we do?’ Walk through it. Make sure principles actually work.
What You Walk Out With
- Team charter. Mission, operating principles, decision rights, communication norms. Everyone shaped it.
- Operating agreements. How we communicate. How we disagree. How we make decisions. How we handle conflict.
- First sprint planned. Clear ownership. Team ready to execute Monday morning.
- 30-day follow-up call to check which norms stuck and which need adjusting.
Pick This If
- Team forming (reorg, new hires, new project)
- Sprint starts within 2 weeks
- Want to skip the 90-day stumbling phase
- Team needs to perform fast (tight deadline, competitive pressure)
Different from Team Operating System
- Team OS = existing team, redesign how you work
- Team Kickoff = new team, design it right from the start
Sprint 3: Someone new joins. Reads the charter. Asks one clarifying question. Productive same day. No fumbling for 2 weeks.
Performance Breakthrough
Turn around teams that aren’t shipping. Fast.
Quarter 3. Same team. Still underperforming. Velocity 50% below target for two quarters.
VP wants weekly updates now. Your best senior engineer started taking calls—he asked to go remote Tuesdays. That’s interview day. Two more people updated their LinkedIn.
You’re thinking about restructuring. But you like this team. They’re good engineers. Something’s broken.
Before you blow it up, try fixing the system.
What This Looks Like
Platform team. Underperforming 3 quarters. Missed every deadline. VP ready to restructure. People quietly interviewing.
Workshop started with brutal honesty. No blame—just what’s actually broken. Two people said out loud: ‘I don’t know what I’m supposed to be working on.’
Found it: 15 work items in progress. Zero owners—‘team owns it’ meant nobody owned it. Critical tech debt blocking everything. Process designed when team was 5, now they’re 12.
Result: WIP limit of 5. Single owner per item. Two-week sprint to clear blockers. Sprint 1: shipped 3 complete items (previous: zero). Sprint 8: above target for first time in a year. Senior engineer cancelled his interviews.
How It Works
Morning’s hard. Honest conversation about what’s broken. Anonymous input if needed—sometimes people won’t say things out loud until they see others wrote the same thing.
Then we diagnose. Not symptoms—root causes. ‘Velocity low’ isn’t the problem, it’s the symptom. Keep asking why until you hit something you can actually fix.
Usually find 2–3 core issues. Too much WIP. Unclear ownership. Tech debt. Bad process. Then we fix those specific things. Not everything—just the 2–3 things creating all the chaos.
Theory of constraints applied to teams: Fix the bottleneck. Only then does everything else speed up.
What You Walk Out With
- Diagnosis. The actual root causes. Not ‘team has performance issues’—specific systemic blockers with names.
- Recovery plan. What changes Monday. What gets measured. Clear owners. 30-day focus.
- Two-week check-ins for first month. We adjust as you learn what’s working.
- You’ll know it worked when someone says ‘remember when we couldn’t ship anything?’ and everyone laughs.
Pick This If
- Team underperforming 2+ quarters, tried normal fixes
- Leadership losing patience, restructure being discussed
- People looking, morale tanking
- You like the team but something’s clearly broken
Cost of Waiting
- Every quarter: team loses credibility, top performers leave
- Projects fall further behind, eventually forced to restructure
Eight weeks: Velocity doubled. First clean win shipped. People stopped interviewing. Team remembers what it feels like to win.
OKR Alignment Workshop
Set OKRs that actually drive decisions. Not collect dust in a Google Doc.
Your OKRs for this quarter? Beautiful Google Doc. Colour-coded. Looks great.
Set them in January. It’s April. Doc has 12 views total. Nobody’s looked at it since week 2.
Last week, feature request came in. PM made the call. Never checked if it served the objectives. You’ve done OKRs for 3 years. They’ve never worked.
It’s theatre. You know it. Team knows it. Everyone’s going through the motions.
What This Looks Like
Growth-stage startup. Set ambitious OKRs every quarter. Deck always looked impressive. Then everyone went back to work and just… did stuff. Reacted to escalations. Took sales requests. Quarter ended, graded themselves yellow on everything.
Real problem: OKRs stayed abstract. ‘Improve customer experience’—what does that mean Monday? Engineer couldn’t answer. So they ignored it.
One session: Translated fluffy OKRs into engineering language. ‘Grow revenue 40%’ became: P95 API latency under 200ms (unlocks enterprise tier), ship SSO (blocking 3 deals), zero critical production bugs for 30 days (NPS tanking from reliability).
Result: Hit 3 of 4 key results. First time ever. Tech Lead used OKR dashboard to say no to Sales. ‘Showed them the dashboard. They actually accepted it.’
How It Works
Start with company OKRs. Usually abstract. ‘Increase revenue 40%.’ Fine for executives. Useless for engineers.
We break them down. What would engineering have to DO to contribute? Ship features that unlock enterprise tier. Improve performance. Build integrations. Get specific.
Key results get the ‘can we measure this Friday?’ test. Not ‘better performance.’ P95 latency under 200ms. Not ‘more reliable.’ Zero critical bugs for 30 days. Numbers. Dates. Binary yes/no.
Build check-in rhythm that’s not theatre. Weekly: 15 minutes. Dashboard with red/yellow/green. If something’s red, what are we doing about it? Quick. Operational. Not a status meeting—a working meeting.
What You Walk Out With
- OKRs that connect to daily work. Engineer knows: if I’m working on this, it serves key result X. If not, why am I working on it?
- Dashboard. Real status. Weekly. When stakeholder asks ‘can we add this?’ PM checks dashboard, gives data-driven answer.
- Integration plan. How OKRs show up in standups, sprint planning, and weekly reviews. Not a separate process.
- 30-day follow-up call to check integration and adjust what’s not working.
Pick This If
- Have OKRs but they don’t drive decisions
- Team doesn’t know how work connects to company goals
- OKRs feel like performance theatre
- Set them in January, forget them by February
Why Now
- If next quarter starts in 2–4 weeks, set them RIGHT this time
- Otherwise it’s another quarter of Google Docs nobody opens
Mid-quarter: Feature request lands. Team checks OKR dashboard. Doesn’t serve any objective. Says no with clear reasoning. First time OKRs actually helped make a decision.
Quick Comparison
Still not sure? Here’s each workshop in one line.
Innovation Engine
Ideas everywhere. Nothing ships. Need a system.
Quarterly Planning
Plans don’t survive week 3. Need real accountability.
Product Roadmap
Stakeholders pulling in different directions. Need alignment.
Team Operating System
Team runs on vibes. Need documented norms and systems.
Team Kickoff
New team. Need shared norms before bad habits form.
Performance Breakthrough
Good team, stuck output. Need to find the real constraint.
OKR Alignment
OKRs exist on paper. Nobody uses them daily.
Which Workshop Do You Need?
Quick decision guide based on your biggest challenge right now.
“Leadership pushing ‘innovation culture’ but team has no system for it.”
Innovation Engine →“We do planning but it doesn’t stick. Mid-quarter requests derail everything.”
Quarterly Planning →“Roadmap debates circle forever. Stakeholders can’t align.”
Product Roadmap →“Smart people keep clashing. Meetings are tense.”
Team Operating System →“New team forming. Want to skip the 90-day stumbling phase.”
Team Kickoff →“Team underperforming 2+ quarters. People looking.”
Performance Breakthrough →“Have OKRs but nobody uses them.”
OKR Alignment →Not sure which workshop?
Book a 30-minute call. No pitch. We’ll figure out which workshop fits — or if you need something different entirely.
Book a CallAll Core Workshops: Full-day commitment. Framework built. Team owns it.