A pitch deck team slide should explain why the people involved can execute the next important step. Show who owns the work, what relevant evidence supports that responsibility, and where the team still has a gap. A row of job titles and impressive logos may describe a résumé without answering any of those questions.

Build the slide around your next milestone, then select the team facts that help explain it. You can turn your business material into a pitch deck draft once those facts are ready. Review the resulting slide carefully: a design tool cannot establish someone’s experience, availability or commitment on your behalf.

Three complementary areas of responsibility connect to a shared pilot milestone, with advice shown separately from delivery.

Start with the work the team must do

“We have a strong team” is difficult to evaluate. “Product, engineering and onboarding have owners for the first pilot” gives the audience something concrete to examine. The second statement does not prove that the pilot will succeed; it identifies the responsibilities that must be covered.

Choose one near-term milestone from the business plan. It might be completing a prototype, running a pilot, delivering a first customer deployment or testing a distribution channel. Break it into a few necessary work areas before deciding whose biography belongs on the slide.

Sequoia’s business-plan outline includes founders and key team members. That is a reason to explain the people relevant to the business, not an instruction to include everyone with an impressive connection. A team slide and a company organization chart answer different questions.

For each work area, ask what evidence would make the proposed owner credible. Relevant work might be a prototype they built, a process they operated, a decision they made or research they can explain. Seniority and a recognizable employer may provide context, but they do not describe the person’s contribution by themselves.

A fictional team with a specific milestone

Consider a fictional scheduling business preparing a six-week pilot with three prospective repair businesses. The people and work below are invented to demonstrate the slide; they are not Presenti customers or real endorsements. No pilot contract is assumed to have been signed.

The milestone is to prepare and run that small pilot with usable scheduling flows, a reliable import process and clear onboarding responsibilities. The team has two full-time founders and one part-time operations lead.

Person and current roleRelevant evidence in the exampleResponsibility for the next milestone
Maya — product cofounder, full-timeLed four prototype walkthroughs and turned scheduling conflicts into twelve acceptance scenariosOwn the pilot scope and decide which workflow issues must be resolved before use
Leo — engineering cofounder, full-timeBuilt a sample-data import prototype that identifies missing required fieldsOwn import reliability and prepare a recoverable process for handling failed imports
Nina — operations lead, two days per weekMapped onboarding responsibilities and drafted the handoff for unresolved questionsCoordinate onboarding sessions and route questions to the responsible founder

The evidence is intentionally narrower than a claim of traction. Four walkthroughs do not prove demand. A sample-data prototype is not a production reliability result. An onboarding plan does not establish that customers have completed onboarding. Each fact supports a particular responsibility without being promoted into a broader achievement. Use a separate traction slide with dated customer and usage evidence when explaining what customers have actually done, rather than who is responsible for the next milestone.

This table is the working material. The presentation slide should compress it into short, readable statements while keeping those boundaries intact. Put fuller supporting detail in notes or an appendix if it is likely to be discussed.

Choose proof that survives a follow-up question

A useful proof statement identifies an action and its scope. “Experienced in product” leaves the audience guessing. “Translated four prototype walkthroughs into twelve acceptance scenarios” says what the person did and what resulted. In a real pitch, the team should be able to explain the scenarios and how they influenced the work.

Do not make the wording stronger than the evidence. “Worked at a company that scaled internationally” is not the same as “led international expansion.” “Contributed to a launch” is not the same as owning the launch. If the person’s contribution was one part of a larger team effort, name that part.

Numbers help when they describe a relevant, verifiable scope. They distract when they merely decorate a biography. A count of years does not explain whether someone has solved the problem at hand; a long list of previous employers does not show which experience matters now.

Before using a real claim, identify the supporting artifact or person who can confirm it. That might be a product release, a public publication, a documented project contribution or a work example the person is allowed to discuss. Do not place confidential material, customer names or employer logos on the slide simply because they would look persuasive.

The evidence can also be current work. A first-time founder need not invent a senior background. A clearly scoped prototype, a careful operational model or a well-explained technical choice can tell the audience more than a vague claim to be a “visionary.” Describe what exists and what remains untested.

Turn the evidence into a slide people can read

For the fictional team, use the headline “Product, engineering and onboarding have owners for the first pilot.” Place three equal-sized cards below it. Give each person the same types of information so the audience can compare responsibilities without decoding three different biography formats.

Maya — Product cofounder
Full-time · Four prototype walkthroughs translated into twelve acceptance scenarios.
Next: own pilot scope and workflow decisions.

Leo — Engineering cofounder
Full-time · Sample-data import prototype identifies missing required fields.
Next: own import reliability and recovery.

Nina — Operations lead
Two days/week · Onboarding ownership and question handoff mapped.
Next: coordinate onboarding and route unresolved issues.

Names and responsibilities should be easier to read than background decoration. If you use photographs, use appropriate, permissioned images of the actual people. Do not substitute generated faces for team members. A text-led slide is better than a portrait that implies a person or commitment that does not exist.

Keep each card to the evidence most relevant to this milestone. The slide is not a miniature CV. A qualification, former role or technical specialty belongs when it helps explain the current responsibility; otherwise it can remain in the supporting biography.

The team’s stage determines the useful emphasis. A research-led business may need to explain who can translate research into a usable product. A service business may need delivery ownership. There is no need to imitate the job-title mix of a larger company when those roles do not exist in yours.

The fictional pilot team slide gives Maya product scope, Leo import reliability and Nina onboarding coordination, with a separate note that dedicated support is not yet hired.
Use the same role, evidence and next-responsibility structure for each person; keep the unfilled role visible.

Separate advice from operating responsibility

Suppose the example team also has Ravi, a former operations manager who provides two hours of advice each month. His contribution is reviewing the onboarding handoff. He is not the pilot delivery lead and does not cover day-to-day support.

Put him in a clearly labeled advisor line rather than a fourth operating-team card: “Ravi — operations advisor; two hours/month on onboarding handoff.” The title, involvement and description should reflect an actual agreement in a real pitch. Do not imply that someone is an advisor merely because they answered a question or attended a meeting.

The same distinction applies to contractors and part-time contributors. State their current role and scope. “Engineering partner for the prototype” does not mean the person is a full-time technical cofounder. If an outside specialist owns a critical part of delivery, explain how that responsibility fits with the internal team.

Advisor experience can help explain access to judgment. It cannot fill an operating gap that the advisor has not agreed to cover. Keeping these categories separate makes the slide easier to trust and prevents an audience from assuming more capacity than the business has.

Show the missing role and the current owner

The fictional team does not yet have a dedicated support hire. Hiding that fact would make Nina’s part-time schedule look more comprehensive than it is. Add a small line beneath the team cards: “Dedicated support role not yet filled; Maya owns customer triage and Leo owns technical escalation during the pilot.”

That statement identifies present coverage without claiming unlimited availability. Before the pilot starts, the team still needs to agree coverage hours, how questions reach the owners and what happens when they cannot respond. A hiring plan is not a current employee, and planned funding is not a completed hire.

A gap belongs on this slide when it materially affects the milestone. Name the missing capability and the current arrangement; reserve detailed staffing costs and hiring dates for the operating plan. Do not fill the slide with speculative future titles that make the current team look larger.

Use the slide to explain how the team works

When presenting, connect the people rather than reading their cards aloud. For the example, a short explanation could be:

“Our next step is a small six-week pilot. Maya owns the workflow scope, Leo owns import reliability, and Nina coordinates onboarding two days a week. They have already produced the acceptance scenarios, sample-data prototype and onboarding handoff shown here. We have not yet hired dedicated support, so Maya handles customer triage and Leo handles technical escalation. Ravi advises on the handoff; he does not run delivery.”

This tells the audience who does the work, which preparation exists and where capacity is limited. It leaves room for a useful follow-up about the pilot instead of inviting them to infer responsibilities from titles.

To prepare a draft, supply each person’s current role, time commitment, one relevant evidence statement and next deliverable as separate fields. Include advisor and unfilled-role information explicitly. Then read the drafted slide against those facts: remove any upgraded title, invented achievement or implied commitment. The finished team slide should make the operating arrangement clearer than the biographies alone.