Skip to content

Build a Hiring Pitch for a Key Employee, Not Another Investor Deck

Business

Build a Hiring Pitch for a Key Employee, Not Another Investor Deck

The investor deck and the hiring pitch can share a room, a logo and a founder, and still be answering different questions. One asks a stranger to believe in a future. The other asks a person to spend their working life inside the present. Founders often reuse the first for the second because they have it open and it is beautiful. The trouble is that a candidate evaluating a job is not a smaller version of an investor deciding on risk. They need to know what the work is, what they may decide, what they will be handed, and what is already known to be hard. The business case can live in the same document, but the role has to come first.

There is a structural reason this goes wrong. A company presentation is built to generate confidence in the company's trajectory. A role pitch is built to give a person enough information to judge a working relationship. Those goals are compatible, but they are not identical. A deck that explains why the company will win does not explain why this job is doable. A deck that describes a mission does not describe who approves the redesign. Reusing one for the other is not dishonest; it is a category error, and candidates feel it as a vague unease.

What follows is a paper example: a fictional company and a fictional first design role, created to make the decisions visible. It is not a real vacancy, not employee testimony, and no hiring presentation described here has been tested, approved or reviewed by anyone. The point is to show a method you can apply to your own real facts.

Start with the work that needs an owner

The instinct is to open with the company story: the category, the growth, the moment. For a candidate that opening is inert. They did not ask to be at the company's next chapter. They asked what needs doing. Open with the problem that has no owner yet.

In the fictional example: the company sells a workflow tool used by small operations teams. Founders have a working assumption, based on what support and sales describe and what the product's usage suggests, that the same problem keeps surfacing. New customers arrive, do an initial setup, and then cannot work out how the product's separate features fit together across a normal week. The features exist. The sequence does not. The company has decided that someone has to own the end-to-end workflow and make it coherent.

That paragraph does a job an investor slide cannot. It connects the role to a current, assumed problem. It says what the work is, not what the title is. It also hints at what a candidate will be walking into: an existing product, real usage, and a mess that no one has been willing to own.

The mandate can then be stated in one sentence that the candidate can hold: Own the design of the customer workflow from first meaningful use to routine weekly use, and be accountable for whether people can complete it without help. That is a real responsibility. It is also bounded. It is not "own design."

Notice that we have not mentioned future scale. Future scale can appear later, clearly labeled, and only where it changes the decision. "We expect the team to grow" is a hope. "Within the first two quarters, this role is expected to work with the current product setup; future team structure is not yet decided" is a condition. Candidates make better decisions with the second.

Make authority match responsibility

Once the work is named, the founder's instinct is to reassure. "You'll have complete autonomy" sounds generous and tells a candidate nothing they can rely on. Autonomy over what, against whose priorities, with what recourse when someone disagrees?

The useful structure is a plain list of three things: decisions the role owns outright, decisions where the role proposes and someone else approves, and conflicts that have a named resolver. Write it down before the candidate asks, because they will ask, and an improvised answer in the meeting is where trust either begins or quietly dies.

In the fictional example, the role's decision rights are:

  • Owns: the structure and sequence of the customer workflow; how features are introduced within it; what a disabled state or an empty state says; how the workflow is documented for the user.
  • Proposes, someone else approves: which features are worth building to support the workflow. The role argues the case; the product collaborator and a founder make the call.
  • Conflicts resolved by: the founder, within one week of a written disagreement. If the disagreement is about release timing, the release decision owner resolves it, and the design lead is expected to state a view in writing.

This is a smaller, less flattering picture than "you'll be in charge of design." It is also a picture a candidate can test in an interview. They can ask what "one week" actually looks like, whether written disagreement has happened before, and who the release decision owner is.

That last point matters. The fictional role depends on a product collaborator — one person — to turn design decisions into buildable work, and on that same collaborator to represent customer input. Those are two dependencies carried by one shared person, and the constraint compounds: the same collaborator who must make the work buildable is also the one who must relay what customers say. Both dependencies should be named, not implied. Naming them does two things. It lets the candidate estimate whether the mandate is achievable, and it lets them see how thin the relay between design decisions and customer input actually is. It also lets them see how the company understands its own bottleneck. A founder who names the shared dependency is usually telling the truth; a founder who claims the design lead will be unblocked by everyone is usually not.

Show resources and difficult conditions honestly

Resources are where the investor deck habits do the most damage, because "we're hiring" and "we have budget" sound like resources and are not. A candidate needs to distinguish what exists now from what is planned.

The useful split is: confirmed, planned, and hoped. Confirmed means a person, tool, budget line or data access that exists today, with a name. Planned means a decision has been made and a timeline exists. Hoped means someone would like it.

In the fictional example, the honest version might read:

  • Confirmed: one product collaborator (full-time, and shared with other work; the same person also relays customer input, so this is one resource carrying two dependencies). Existing customer support team, reachable for research conversations. A usage analytics tool. A weekly slot in the release process.
  • Planned: a dedicated user-research contractor, to be hired within the first quarter, subject to budget approval. The candidate would help define the brief. The role does not currently have research capacity of its own.
  • Hoped: a second designer, so the workflow work is not competing with incidental requests. No decision yet.

That list is more useful than any reassurance, and it turns the conversation toward things a candidate can actually question. They will notice the empty research box. They will notice that the product collaborator is shared. They will ask whether the incidental requests arrive anyway, because in most small companies they do. That is a better use of the room than hearing that the culture is collaborative.

The same principle applies to difficult conditions. Name them specifically and without theatre. "The workflow is currently documented in five places, one of which is a spreadsheet owned by support." "Two enterprise customers have customized their setup, and the redesign has to account for both." "The last attempt at this stalled eight months ago; the reasons are partly known and partly a matter of dispute." Each of those is a fact a candidate can work with. "It's a fast-paced environment" is not.

The temptation here is to invent warmth. Do not. If you do not know why employees stay, do not claim it in the pitch; let the candidate ask people who actually work there. A role pitch should not be a place for confident claims about culture, only for specific, checkable conditions.

Connect the company story to the candidate's decision

The company story still matters, but its job changes. In an investor deck it argues for funding. In a hiring pitch it explains why this particular work is worth a person's time, and what would make it difficult. That usually means selecting fewer, truer facts.

For the fictional example, three things do the work:

  • The product is used by small operations teams whose week is more repetitive than their job titles suggest. Support and sales report that this problem is what makes the product either stick or get abandoned; the founders treat that as a working assumption, and the role is expected to test it.
  • The company has not previously had a design lead, and product decisions have been made by the product collaborator and a founder. The person taking this role will be changing how decisions are made, not just making them.
  • A previous effort to restructure the workflow was paused when two large customers requested conflicting customizations. That history is known inside the company and relevant to anyone considering the work.

None of these is a projection. Each rests on something the company can point to — its usage, its history, or an assumption it is willing to name — and each changes what the candidate would be stepping into. Future ambitions can appear after that, labeled as ambitions: for example, "the company intends to publish design decisions openly to customers in the next year, but that decision is not yet made." Labeling the ambition protects both sides. The candidate knows what they are being sold and what they are not.

Compensation and ownership terms belong in authorized documents, not in a pitch deck or a meeting improvisation. A pitch that gestures at equity to make a modest cash number feel larger is doing the candidate harm. A pitch that implies that a leadership title carries an ownership stake is worse. If the terms are not yet authorized for discussion, say so, and keep the role conversation separate until they are.

Design space for disagreement and clarification

Most company pitches end with a slide of questions, and most of those questions are rhetorical. They are designed to be answered smoothly by the founder and to make the candidate more confident, not more informed. The end of a role pitch should do the opposite. It should leave visible the questions the candidate and the company need to resolve together, and it should say which answers are not yet available.

A short way to do this is a single page titled something like "Open questions for our conversation." Not a list of the founder's favorite answers, but a list of what is genuinely unsettled. In the fictional example:

  • Does the role include responding to ad-hoc design requests from sales and support, or is that explicitly outside the mandate for the first two quarters?
  • If the planned research contractor does not arrive in the first quarter, how does the role adjust? Who decides that?
  • Which of the two customized enterprise setups is negotiable, and who has the conversation with those customers?
  • If the release decision owner and the design lead disagree about a workflow change, what does the escalation actually look like in practice?
  • Is there a written understanding of what "the first quarter" means here, or is that still forming?

None of these questions has a comfortable institutional answer, which is the point. The candidate's ability to ask them and the company's ability to answer honestly are both part of the assessment. A good conversation will leave at least one question genuinely open, and both sides should be able to say so.

Two parts of this are deliberate. First, the pitch should not treat a candidate's engagement as agreement. Enthusiasm in a meeting is not a signal that the conditions are understood, and a founder who reads it that way will tend to reduce the harder parts of the pitch next time. Second, the pitch should leave room for the candidate to conclude that the role is not a fit. That is a legitimate outcome of an informative presentation, not a failure of persuasion. A company that cannot tolerate that outcome is not, in fact, offering a genuine role conversation.

What changes if you reuse the investor deck

There is a lighter version of this, for founders who cannot build a separate document yet. It is not the same thing, but it can be made honest.

Take the investor deck as it is. Then, before the candidate sees it, insert a role section at the front: one page with the mandate, one with decision rights, one with confirmed and planned resources, and one with difficult conditions and open questions. Four pages, prepared once, edited per role. Keep the rest of the deck after the role section, and label everything after it as the company context, not the job.

That insertion does most of the structural work. It makes the role the first thing discussed and the deck the supporting material. It also keeps the founder from using the growth story as a substitute for the role story. If even four pages are not possible, the honest fallback is a single written paragraph in the conversation's invitation that states the mandate, the one named dependency and the one unresolved resource question. That is much less than the full pitch, but it is more useful to a candidate than a deck alone, and it keeps the conversation about the work rather than the company's future.

A candidate-facing mandate, and the questions that remain

If you take one thing from this, make it the paragraph the candidate would read first. Something like:

This role owns the design of the customer workflow from first meaningful use to routine weekly use. You will decide the workflow structure and the sequencing of features within it. You will propose which features to build to support it; those decisions are made with the product collaborator and a founder. You will work with one product collaborator who is also handling other work and who relays customer input, and with the existing support team for research conversations. A dedicated research contractor is planned for the first quarter but not yet confirmed. A previous attempt to restructure the workflow was paused when two large customers requested conflicting customizations; that history is part of the work.

The rest of the presentation should support such a paragraph, not replace it.

The remaining questions are the ones that belong in the conversation, and they should be written down before the meeting so that both sides know what was left open:

  • Which decisions in the mandate are actually the role's, and which are still shared in ways that have not been named?
  • What is the plan if the planned research capacity does not arrive, and who decides the fallback?
  • What happens when the design lead and the release decision owner disagree, in practice rather than in principle?
  • Which of the difficult conditions above is the candidate being asked to accept, and which is the company committing to change?
  • What would the company need to hear from a candidate to conclude that the role is not a fit, and what would the candidate need to hear to conclude the same?

A pitch that can hold those questions is doing the work an investor deck cannot. It is telling a person, accurately, what they would be joining — and letting them decide whether to.

Frequently asked questions

What should a hiring pitch lead with instead of the company story?

Lead with the work that needs an owner. A candidate evaluating a job needs to know what the work is, what they may decide, what they will be handed, and what is already known to be hard. The company story can appear later as supporting context, but it should not substitute for the role.

How should decision rights be presented in a role pitch?

Use a plain list of three things: decisions the role owns outright, decisions where the role proposes and someone else approves, and conflicts that have a named resolver. In the fictional example, the role owns workflow structure and sequencing, proposes which features to build with a product collaborator and founder making the call, and conflicts are resolved by the founder within one week.

How can a founder describe resources without vague reassurance?

Split them into confirmed, planned, and hoped. Confirmed means a person, tool, budget line or data access that exists today, with a name. Planned means a decision has been made and a timeline exists. Hoped means someone would like it. This lets a candidate question what is actually available rather than hearing only that the company is hiring or has budget.

Can an investor deck be reused for hiring?

A lighter version can be made honest by inserting a role section at the front: one page with the mandate, one with decision rights, one with confirmed and planned resources, and one with difficult conditions and open questions. Label everything after it as company context, not the job. If even four pages are not possible, a single written paragraph can state the mandate, one named dependency, and one unresolved resource question.

What belongs outside the pitch itself?

Compensation and ownership terms belong in authorized documents, not in a pitch deck or a meeting improvisation. If the terms are not yet authorized for discussion, say so and keep the role conversation separate until they are. Also do not invent warmth or claims about culture; let the candidate ask people who actually work there.

More in Business Browse all articles