Product Operating Model Series: Instrumentation
Issue #239
In today's edition, among other things:
đ Editorâs Note (by Alex Dziewulska)
đ Product Operating Model Series: Instrumentation
Join Premium to get access to all content.
It will take you almost an hour to read this issue. Lots of content (or meat)! (For vegans - lots of tofu!).
Grab a notebook đ° and your favorite beverage đ”â.
Editorâs Note by Alex đ
For years, product people had a beautiful excuse.
âWe donât have time for strategic thinking.â We said it in standups. We said it in retros. We said it in performance reviews when someone asked why the roadmap looked like a to-do list. We were drowning in bieĆŒÄ czka â the Polish word for the daily current that pulls you along, the busywork treadmill that never stops turning. Stakeholder requests. Sprint ceremonies. Backlog grooming that somehow took longer than building the thing. Status updates about status updates.
Designers complained they were pixel pushers. Researchers complained nobody read the reports â that their insights died somewhere between the presentation and the next sprint planning. Product managers complained theyâd been reduced to glorified backlog managers with a Jira license. And all of us pointed at the same villain: not enough time. If only we had space to breathe, to think, to actually do the strategic work we were trained for.
Then AI showed up. And everything got faster.
Prototyping that took weeks now takes hours. Sometimes minutes. Research synthesis that consumed days happens before lunch. Competitive analysis, user interview summaries, first-draft specs, wireframes, landing page mockups â all of it compressed into a fraction of the time it used to take. We got the gift weâd been begging for. We got time back.
So what are we doing with it?
More prototypes. More iterations. More output. More of the same busy work, just faster. We didnât reclaim the space for strategic thinking â we filled it with more production. Parkinsonâs Law is eating us alive, and weâre too busy shipping to notice.
The research is now confirming what Iâve been watching in real time across my clients and mastermind groups. A Workday study from this year found that 37â40% of time supposedly saved by AI gets consumed reviewing, correcting, and verifying AI-generated output. You save an hour writing a spec, then spend twenty-five minutes fact-checking it because the model confidently cited a study that doesnât exist. Asana surveyed nine thousand workers and found that 90% of the most productive AI users â the top 10%, saving twenty-plus hours a week â report that AI creates more coordination work between team members, not less. The NBER surveyed six thousand executives and found 89% saw no change in productivity, despite AI adoption climbing to around 70% of firms. Faros AI tracked telemetry from ten thousand developers across over a thousand teams â individual output up, PRs up, code volume up. Company-level delivery velocity? No measurable improvement.
Controlled studies show individual task gains ranging from 14% to over 50%, depending on domain. Customer service, writing, coding â faster across the board at the individual level. Organizational output? Flat. The gains evaporate somewhere between the person and the company.
We are faster at doing things that might not need doing.
I know this pattern intimately. I have an ADHD brain. The pull to do â to prototype, iterate, build, ship, move â is not a professional habit. Itâs neurological architecture. And AI supercharges it. I can sit with Claude for hours and produce more tangible output in a single session than some teams produce in a sprint. It feels incredible. It feels productive. And sometimes it is.
But sometimes Iâm three prototypes deep into a problem I havenât actually decided is worth solving.
Thatâs the trap. AI makes execution feel so good, so immediate, so satisfying, that you can skip the hard part entirely and still feel like youâre making progress. The hard part being: should we build this at all? What problem does this actually solve? For whom? Under what conditions? These are strategic questions. They require stopping. They require thinking. They require sitting with ambiguity long enough to form a real opinion rather than iterating your way past the discomfort.
And hereâs what I keep circling back to â maybe we never actually wanted that time for strategic thinking. Maybe we wanted the excuse.
Because strategic thinking comes with a tax. It means making decisions. It means being the one who says âno, we shouldnât build thisâ when the entire organization is excited about it. It means being accountable for a direction, not just a delivery. It means looking at data thatâs ambiguous and forming a position rather than running one more test to defer the judgment call. BieĆŒÄ czka protects you from that. If youâre always building, you never have to defend why you stopped.
I think this is the uncomfortable truth underneath the AI productivity paradox that the economists keep measuring but canât quite explain. Individual task-level gains â documented, real, reproducible. Organizational productivity â flat. The missing piece isnât technology or training or adoption curves. Itâs that the bottleneck was never execution speed. The bottleneck was â and remains â the willingness to think before building, and the organizational architecture that rewards or punishes that thinking.
In this race to build faster, to deliver faster, to show that AI is making us more productive, weâre forgetting something fundamental. Product work is not one person sitting in a room with a language model. There are no solo product builders. Not real ones. Not the ones that last. It takes a village â business people and technologists and user advocates and operations and marketing and sales â to create something that actually works in the real world. The coordination, the alignment, the shared understanding of what weâre building and why â thatâs the work AI canât compress. Because it isnât a speed problem. Itâs a human problem.
And honestly? Those human interactions â the ones that slow us down, the ones that feel inefficient, the messy cross-functional conversations where someone challenges your assumption and you have to actually defend your thinking â those are the moments where strategic thinking happens. Not in the prototype. In the conversation about the prototype. In the argument about whether the prototype should exist.
I love building with AI. Iâm not going back. I prototype ideas in hours that would have taken me weeks. But the moments that actually moved the needle â the real breakthroughs â happened when I stopped building and started thinking. Usually with other humans who could see what I couldnât.
We finally have the time we were begging for. The question is whether we have the courage to use it for what we said weâd use it for â or whether weâll keep filling it with faster versions of the work we were already doing.
Stop prototyping for a minute. Sit with the question.
The answer might be that you shouldnât build the thing at all. And thatâs the most valuable output a product person can produce.
Learn a new discovery framework with our team
Free 4-hour workshop for the Product Art Ă DeStaRe community: Lean Inception
Youâve probably been there: ideas everywhere, backlog growing, stakeholders pushing⊠and the team still isnât fully aligned on what problem weâre solving, for whom, and why now.
This workshop is a practical introduction to Lean Inception â a lightweight discovery framework that helps teams quickly build shared understanding, align on outcomes, and turn fuzzy directions into a clear, testable plan.
â
Free | â±ïž 4 hours | đ§âđ€âđ§ Small groups | đ„ Recording | đ© Weekly micro-lessons after the event
What weâll cover
1) 1h theory: What is Lean Inception (and why it works)
Weâll walk through:
What Lean Inception is (and what it is not)
Where it fits in discovery (before delivery, before âsolutions modeâ)
How it reduces risk: alignment, assumptions, scope, priorities
How teams use it in real-life product work (especially in messy org setups)
2) 3h hands-on workshop: Lean Inception in small groups
Youâll work in a group and go through a Lean Inception flow in practice, step-by-step.
Expect:
structured facilitation
concrete artifacts (not âworkshop theatreâ)
discussions that lead to decisions
short iterations + visible progress
3) Microlearning after the event (weekly)
To help you actually keep using it (not just enjoy the session and forget):
short weekly micro-lessons (tips, prompts, tiny exercises)
âhow to apply in your current productâ angle
small nudges to build the habit
4) Recording
Canât stay for the full session or want to revisit the framework later? Youâll get access to the recording (only for participants)
Who this workshop is for
This will work especially well if you are:
a Product Manager / Product Owner / Product Designer / Researcher / Agile specialist
leading discovery (or asked to) and you want a repeatable structure
tired of misalignment, âtoo many opinions,â and vague requirements
curious how to facilitate discovery with less chaos and more clarity
No prior Lean Inception experience needed.
What youâll leave with (practical outcomes)
By the end youâll have:
a clear understanding of the Lean Inception flow and its purpose
experience applying it (not just hearing about it)
a set of discovery outputs you can reuse in your work (problem framing, priorities, assumptions to test)
a better feel for how to facilitate alignment without overproducing artifacts
How to prepare (simple)
To get the most value:
join from a device where you can actively collaborate (laptop recommended)
bring a real product/topic if you want to apply it directly (optional)
be ready to speak up â small groups work best when everyone participates
Limited seats / small groups
We keep groups small to ensure everyone gets hands-on practice.
Bonus: templates + board
Youâll receive a ready-to-use Lean Inception board/template after the session
Bonus: 30-min optional Q&A / office hours
Quick follow-up session a week later to help people apply it to their context.
Meet other product folks, compare approaches, and learn how others run discovery in practice.
This is not a webinar â expect collaboration.
If you want a discovery framework that helps you align fast, reduce risk, and move from opinions to decisions, join us.
đ Sign up to secure your spot (free for newsletter Product Art Subscribers).
Link: Click here!
AI in Product Work: Practical, Not Theater
MichaĆ Reda is running another cohort of AI Product Empowered Practitionerâą in Marchâa 7-week program for product managers, owners, designers, and analysts who want to actually use AI in daily product work, not just talk about it.
This isnât another mass AI bootcamp with 500 people watching slides.
Hereâs what makes it different:
Real work, not theory: You work on one actual case studyâan existing Polish market product with real and synthetic product data. The workshops are live, hands-on, in small groups (20-25 people). You leave with workflows you can implement the next day.
Actual tools, not demos: Full access to premium toolsâChatGPT Pro, Miro AI, PostHog, Loveable, Claude, and more. You work with them during the program, not watch someone else use them.
Flexibility: Each module offers two live workshop timesâyou choose when it fits your schedule.
Small cohort: Maximum 60 participants. Individual attention actually possible. No hiding in a crowd of hundreds.
Five focus areas: Discovery, delivery, analytics, and the practical AI workflows that connect them.
The first cohort in November 2025 hit product-market fit. Participants reported concrete value: understanding LLM mechanics, building domain context, specific implementations. Sebastian Jelonek: âTreats AI like a partner, massive time savings.â Ćukasz PawĆowski: âConcrete tools for daily work, solid practical approach.â Ćukasz Chomiuk: âMany super practical tasks, examples, AI tools I started using immediately.â
This is Level 1. MichaĆâs building Level 2 (AI Product Development Practitioner) for first half 2026 and Level 3 (AI Product Leader) for second half. Heâs assembling a team of practitioner-trainers for the next stages.
If you want to work smarter with AIânot just attend another bootcamp where you watch someone talk about itâcheck the program details.
Registrations open now. Max 60 participants.
Program details and registration: https://productpro.pl/strona-glowna/ai-empowered-product-practitioner/
This is marathon work, not sprint hype. If youâre ready for practical skill development over seven weeks, this might be worth your time.
đ Product Operating Model Series
Principle 14: Instrumentation â Quick Reference Guide
Product Operating Model | Product Delivery Principles From Marty Caganâs Transformed (2024)
Core Definition
âWithout this instrumentation, you are simply flying blind. You can release a new capability and have little idea if and how it is being used, and where your customers might be struggling.â â Marty Cagan, Transformed
What it is: Ensuring products generate data (telemetry) about how theyâre actually used and performing â at all levels from infrastructure health to user behavior analytics â enabling data-informed decisions about product improvements.
What it isnât: Just installing analytics tools. Itâs a cognitive and organizational intervention that requires engineering implementation.
Why It Matters: The Evidence
The Cost of Flying Blind
80% of features in the average software product are rarely or never used (Pendo 2019 Feature Adoption Report, 615 products analyzed)
Up to $29.5 billion estimated annual waste on unused features by public cloud
