Engagement-Led Product Evolution
Turn repeated user behaviour into the next product capability
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 98%
Engagement-Led Product Evolution uses current behaviour as the input for product development. Begin by examining what users do, discuss, and repeatedly ask one another inside or around the product. Identify the job beneath that behaviour, then remove friction in stages: first make the sought information visible, and later automate the action if use validates the need. eToro began as a trading platform with chat and profiles. Assia said users repeatedly asked what others were trading and whether they still held positions, which led the company to expose portfolios and performance. Once that social visibility existed, automatic copy trading became a logical next capability. The mechanism moves from observed demand to a smaller feature and then to deeper automation, with engagement evidence guiding each step.
Origin
Extracted from The Foundr Podcast
Core principles
- 01Observe what users repeatedly do before deciding what to build
- 02Treat recurring questions and workarounds as product signals
- 03Reduce friction around behaviour that already drives engagement
- 04Build in stages and verify each stage through use
How to run it
- 1
Observe actual use
Review user activity, conversations, support requests, and recurring workarounds. Look for behaviour that appears repeatedly rather than isolated feature requests.
Pro tip Study what users already spend time doing, not only what they say they might use.
Watch out A loud individual request is not necessarily a broad product signal.
- 2
Find the underlying job
Translate the repeated behaviour into the information or outcome users are seeking. Describe the job without assuming a specific feature solution.
Pro tip Group different requests that serve the same user goal.
Watch out Copying the workaround literally may preserve unnecessary friction.
- 3
Expose what users seek
Build the smallest capability that makes the desired information or action directly available. Preserve appropriate privacy, consent, and control.
Pro tip Start with visibility or a lightweight interaction before full automation.
Watch out Visibility features can damage trust if users do not understand what becomes public.
- 4
Validate the behaviour
Measure whether users adopt the capability and whether it improves meaningful engagement. Use the result to confirm or reject the product hypothesis.
Pro tip Define useful engagement before release rather than optimising raw activity afterward.
Watch out More activity is not automatically more customer value.
- 5
Automate the repeated action
When users consistently act on the exposed information, consider automating that action with clear controls. Continue monitoring use and outcomes.
Pro tip Let users preview and reverse automated actions where the context permits.
Watch out Automation increases consequences and requires stronger safeguards than simple visibility.
In the wild
eToro initially offered a trading platform with chat and profiles. Users repeatedly asked others what they were trading and whether they still owned positions, so the company made portfolios and performance visible. Once users could see that activity, eToro added the ability to copy another trader automatically.
→ Observed conversation evolved into social investing features and then copy trading.
A project tool notices users repeatedly asking colleagues whether a task is blocked. It first adds a visible blocker status and measures adoption. When teams consistently use the status to coordinate handoffs, the tool adds an optional alert to the next owner.
→ A recurring coordination question becomes a validated visibility feature and then a controlled automation.
Common mistakes
Building from assumptions alone
A polished feature can miss the behaviour users are already demonstrating in the product.
Automating before validating
Full automation adds complexity and risk before the underlying user job has been confirmed.
Ignoring privacy and control
Making user activity visible or copyable can undermine trust unless disclosure and permissions are clear.
Is it for you?
Best for
It is best for products with enough user activity to reveal recurring conversations, requests, or workarounds.
Not ideal for
It is not ideal before a team has meaningful usage evidence or when observed behaviour creates legal, safety, or ethical concerns.
From the transcript
“you should look at what your users are using your product for and really figure out what drives engagement”
“if everybody's asking constantly people what are what are they doing let's just show them what they're doing”
“if you can see what other people are doing why not 14 00 automatically copy them”
From the episode
354: What Yoni Assia Of eToro Learned During Dinner with Warren Buffett
Yoni Assia