Roles solve problems — not headcount plans.
Kristina Golovko
MindDesign
The problem-to-role model
Problem
Specific, observable, costly
Ownership
Who resolves it — and how?
Outcome
What does solved look like?
Role
The job that exists to deliver it
The job description is the last step, not the first. Define the problem before you define the person.
Why this matters
A job title is a category. A problem is a specific, observable condition that is limiting the business. These are not the same thing — and most hiring processes confuse them.
When a company hires a 'Head of Marketing' because they feel they need one, the result is a search shaped by industry convention rather than business context. The candidate is evaluated against a generic profile, not against the actual constraint the business is facing.
The best hiring processes start with a precisely defined problem. The role emerges from the problem — not from an org chart or a peer company's headcount.
Founder reality
Before writing the job description, define the problem with precision:
What is the specific, named business problem this hire will resolve?
Who currently owns this problem — and why isn't that working?
What would 'solved' look like at 90 days, 6 months, 12 months?
What decisions will this person make that nobody else is making today?
Is this problem strategic or operational — and does the role reflect that?
If you cannot answer these questions before writing the JD, the role isn't ready to open.
The framework
Three steps that turn a vague hiring intention into a precise role definition.
Define the problem — specifically and observably
Not 'we need better marketing' — but 'our conversion from trial to paid is 3.2% and we don't understand why.' Not 'we need more engineering support' — but 'our deployment cycle is 6 weeks and the bottleneck is a manual QA process that nobody owns.' Specific problems produce specific roles.
Map current ownership — and identify the gap
Every problem has a current owner, even if informal. Understanding who currently touches the problem — and why the solution isn't working — defines the gap the new hire must fill. A gap in capability is different from a gap in capacity or a gap in ownership.
Define the outcome — not the activity
The role exists to produce a specific outcome. Define it clearly: what changes in the business when this person is performing well? Activities (meetings, reports, campaigns) are not outcomes. Revenue, speed, quality, and structural improvement are outcomes.
Common mistakes
01
Writing the job description before defining the problem
The JD becomes a wish list of skills rather than a precise specification for a specific problem. The result is a broad search that attracts broadly, filters poorly, and decides slowly.
02
Defining the role by analogy to other companies
What a Head of Product does at Stripe is not what a Head of Product does at your 15-person deep-tech startup. Context defines the role — not convention.
03
Confusing ownership with accountability
Hiring someone to 'own' a problem without giving them the authority to change what causes it produces a frustrated hire and an unchanged problem.
04
Measuring activity instead of outcome
If you don't know what the role is supposed to produce, you can't evaluate whether it's working. Six months in, you're assessing presence rather than performance.
Example scenario
An AI safety startup, 20 people, seed-funded. The founder wants to hire a 'Head of Partnerships' because 'we need partnerships to grow.'
The surface request
'We need someone to manage our partner relationships and find new opportunities.'
What problem definition revealed
The company had two existing partnerships that weren't being activated — not a sourcing problem, an activation problem.
The actual bottleneck was that no one had created partner integration documentation — so partners couldn't self-serve.
New partnerships were being blocked by a 3-month legal review cycle, not by lack of leads.
The 'Head of Partnerships' role was really a 'Partner Success and Enablement' role — a very different profile.
The decision
A partner enablement manager was hired instead of a Head of Partnerships. The legal process was fixed separately. Within 90 days, existing partnerships were generating referral pipeline. The company deferred the senior partnerships hire until the motion was proven.
The problem defines the role — not the other way around.
Start with a precise problem statement. Let the role emerge from it. The result is a search that's faster, a brief that's sharper, and a hire that has a real chance of working.
Continue reading
Role Clarity Before Hiring →