Impact-Over-Output Operating Model
Measure teams by validated impact on customers, not by features shipped — and prove the needle moved
- Difficulty
- Moderate
- Time to result
- ~ongoing to results
- Steps
- 5
- Confidence
- 95%
Orient the whole team around impact rather than output. Before building, a PM must create shared understanding of the problem/opportunity AND define how you'll know you moved the needle. The entire team succeeds or fails together based on customer value, and the biggest impact is often not a new feature but making existing value accessible.
Origin
Daniel Lereya's core operating principle at monday.com, crystallized after the columns hackathon. He frames a great PM as 'someone that is relentless until he gets this impact and validates that this impact is in place.'
Core principles
- 01A great PM is relentless until the impact is validated, not until the feature ships
- 02Define two things before building: what the problem/opportunity is, and how you'll know you moved the needle
- 03The whole team succeeds or fails together on customer value — it's not just the PM's job
- 04The biggest impact is often making existing value more accessible or better connected to go-to-market, not a new feature
- 05Working extremely hard is not evidence of success
How to run it
- 1
State the problem before the solution
Have the PM create shared understanding of what problem or opportunity is being addressed, and spend real time in the problem space before discussing any solution.
Pro tip Once the goal is committed, debates about competing solutions shrink automatically, because everyone knows every option will be tested in real life.
Watch out Watch for vague verbs — 'enhance,' 'augment,' 'extend value' — as a smell that no real goal exists.
- 2
Define the needle-moving metric up front
Commit to a measurable target: what should change for users, and how will you see for sure that it happened. Working backward from a business-growth number reveals the levers most likely to move it.
Pro tip A committed goal forces you to size your target audience — you need a big enough audience for the change to reach your number.
- 3
Instrument a daily numbers update per team
Every team maintains a daily message with the numbers they care about (e.g. AI actions, accounts using a feature), pushed via an internal system into a shared channel for discussion.
Pro tip Push the numbers to people rather than making them go look — 'you need to get your numbers in push, you need to live by them.'
- 4
Interrogate anomalies and remove the real blocker
When the numbers reveal the impact isn't landing, find the actual constraint — which is often not more building — and clear it fast.
Pro tip The blocker is frequently non-engineering (legal, terms of service, discoverability, go-to-market). Prioritize clearing it over building more.
Watch out You can build great value, get great feedback, and still miss the impact you aimed for if a non-product blocker caps adoption.
- 5
Run a periodic backward-looking impact check
On a cadence (quarter / month / two weeks) ask: how will the product be different and better for customers in a quarter, and work backward from that. Also ask individuals what they're most proud of from the last three months.
Pro tip If it takes someone a long time to name what they're proud of, they're not focused and not maximizing impact.
Watch out Answers like 'better security, better performance, fewer bugs, more enhancements' are not enough — they don't name a pivotal change in customer value.
In the wild
monday.com shipped AI Blocks (no-code AI actions inside workflows) and saw strong feedback and rising AI-action usage in the daily numbers. But one day the team noticed only a few thousand of 250,000 paying companies were using AI. Digging in, someone revealed AI was gated behind a terms-of-service change scheduled for next quarter. Lereya insisted on doing it now.
→ Within two weeks, AI was opened to 98% of monday.com customers — unlocking the impact that building alone would never have delivered.
Common mistakes
Falling in love with building and losing the why
Lereya admits 'we all love to build things' and once you start you get excited and lose track of why you're doing it. A huge part of what he personally built was never used the way he expected, because the goal wasn't defined as a validated change in customer behavior.
Using enhancement language instead of a target
Saying you'll 'enhance,' 'augment,' or 'extend value' with no statement of what changes for users and how you'll measure it is the clearest sign you're output-driven, not impact-driven.
Is it for you?
Best for
Product leaders and PM teams at growth-stage software companies who ship a lot but struggle to point to what actually moved the business
Not ideal for
Pure infrastructure or research work where value is deliberately strategic and not yet measurable by near-term customer metrics
From the transcript
“a great PM basically for me is someone that is relentless until he gets this impact and until he validates that this impact is in…”
“it's about what's the problem, what's the opportunity and second how we will know that we move the needle”
“in some cases doing the biggest impact is not developing another feature. It's about making the current value more accessible”
“each team at Monday has like what we call the daily numbers update”
“you need to get your numbers in push you need to live by them”
From the episode
Inside monday.com’s transformation: radical transparency, impact over output, and their path to $1B ARR
Daniel Lereya (Chief Product and Technology Officer)