World IA Day RVA 2027
The premise
Building is no longer the hard part. Knowing what to build, for whom, and when is.
In the space of two years, the cost of making software, content and campaigns has collapsed. A prototype takes an afternoon. A feature takes a prompt. And yet the number of things worth building has not grown at the same rate. What has grown is the pile of things that were built quickly, shipped confidently, and quietly failed to matter.
Building Context in Problem Spaces is a gathering for the people who have to close that gap together: product managers, designers, researchers, engineers, marketers, data scientists and the leaders who fund them. It starts from one claim. When execution is cheap, shared understanding of the problem becomes the scarcest asset a team has, and the one most worth investing in.
Why now
Everyone is being called a bottleneck. Research slows the sprint. Design slows the release. Review slows the merge. The pressure from founders and owners is the same everywhere: go faster. But speed is only valuable in the right direction, and direction is exactly what has become hard to find.
Five forces are colliding:
Building is cheap; judgment is not. When production stops costing human hours, the old natural brake on bad ideas disappears. Teams can now ship the wrong thing faster than they can notice it is wrong.
Value is measured in profit, and the clock is short. Output that does not turn into revenue or margin is read as waste. When it fails to, the correction is not a retro. It is a layoff.
The environment is high-entropy. Markets, platforms, regulation and customer expectations are shifting at once. Every economic actor is moving, so the problem you understood last quarter may not be the problem you face this one. Timing has become as important as the idea.
Context is fragmented. Every discipline holds a piece of the evidence: telemetry, interviews, support tickets, pipeline data, the codebase. No one holds the whole picture. Four teams can look at the same feature and reach four different conclusions, each partly right.
The team itself is being redesigned. Job posts now ask for a single "builder" who understands the user, makes the call and ships it. In small teams, product, design and engineering are converging into one or two people working with AI. In large organizations, the same roles are expanding and overlapping instead. Either way, the question of where context lives, and who holds it, is open again.
The result is a familiar loop: work fast, decide with partial context, decide wrong, rework, lose trust, cut the people who were supposed to know better. This conference is about breaking that loop.
The questions we're gathering around
A problem space is not a backlog. It is the territory around a decision: who is struggling, with what, under which circumstances, why existing options fall short, and why the opportunity exists now and not two years ago. Mapping that territory has always been someone's job. Now it has to be everyone's, and it has to happen at the speed of the business.
We want to spend the day on these questions:
What is the right problem? How do teams tell a real, valuable problem from an observable pain that every competitor has also spotted? Where does a distinctive belief about value come from, and how is it tested?
When is the right time? How do you read timing in a market that will not hold still? What signals say a problem is ripe, early, or already gone?
Who holds the context? One builder with AI, a pair, a team, or a whole organization? What changes about understanding when the roles that used to share it converge into one person, and what changes when they expand instead?
How is context shared? How do product, design, engineering, data and marketing combine partial evidence into one picture without flattening what each discipline sees?
Can building be a way of understanding? When a prototype costs an afternoon, how do teams use what they build as probes into the problem space, and tell what is useful from what is merely new?
How does context stay alive? If understanding is infrastructure, what are its sources of truth, who maintains it, and when does evidence expire?
Where does judgment sit? How do teams decide what should exist, and agree when to stop, before the first ticket rather than after launch? How does that understanding survive the move from problem to solution?
What do machines change? AI can connect information at scale. What does it take for that to become shared understanding rather than faster confusion?
Call for speakers
We want talks that show how real teams built shared understanding under real pressure, including where it broke. Practice over theory, receipts over frameworks.
We're especially interested in:
Cross-functional case studies, ideally co-presented by people from two or more disciplines who worked on the same decision.
Honest failures: the well-researched product that missed its moment, the fast launch that cost a team, the metric that pointed the wrong way.
Timing stories: how a team knew it was the right moment, or learned too late that it wasn't.
Working artifacts: decision maps, shared vocabularies, evidence standards, stopping conditions, context systems for AI. Show the actual thing.
Prototypes as probes: experiments that changed how a team understood the problem, not just what it shipped.
The profit link: how understanding the problem space showed up in revenue, margin, retention or avoided cost.
Dissent: arguments that shared context is overrated, that speed really is the strategy, or that one builder with AI can hold the whole problem space alone. We want the case for converging roles argued as seriously as the case for expanding ones. We want that debate on stage.
Format: 35-45 minute talks + 5 minutes of Q&A.
Send proposals to bogdan@startup-iq.com with "WIAD RVA 2027 talk" in the subject line.
Thank you, and see you soon!