Southern Adventist University · School of Business
CLIMBCenter for Learning in Innovative Missional Business
IMPACT

Builder's Field Guide

MGNT 288/488 — Community Ventures Lab
Business as a force for social good — now and for eternity.
01Canvas 02Design 03Test 04Evolve
Start here
Before you open a single tool

One distinction shapes everything

Impact is for builders who believe business is a force for social good. You see a need in a community and you want to do something about it — seriously, with tools and accountability, not just good intentions. Here is the one line that separates Impact from its sibling program, Forge.

Impact · MGNT 288/488

The community owns the project

  • Community-owned project
  • The community defines the need; the team serves it
  • Success = measurable impact for the people served
  • The community carries the long-term stake
Forge · MGNT 291

You own the venture

  • Student-owned venture
  • You define the mission, market, and model
  • Success = a venture that is real, tested, and moving
  • You carry the risk — and you keep the reward

The tools in this guide are built for community builders — not solo founders. They ask about listening, serving, and sustaining impact for people whose problem you do not own. If the idea is yours to build and yours to profit from, Forge is your track.

How Impact works

Four phases. One arc.

The path moves from listening to lasting change: from a need you have only just heard, to a project delivering measurable impact for the people it serves. Each phase has its tools and ends at a gate you clear with evidence, not optimism.

1
Canvas Listen first · chase the real problem

Understand the problem — and the people it affects — before designing anything.

Tool 1 · Problem Discovery Canvas GateA real user confirmed the problem in their own words.
2
Design Generate before you filter

Generate real solution options, then filter them honestly before testing any of them.

Tool 2 · Solution Design GateAt least three distinct ideas, filtered by Desirable / Feasible / Viable.
3
Test Pilot before you build

Pilot-test your strongest idea with real people before committing a semester to it.

Tool 3 · Pilot Test Board GateYou tested an idea with real people — and can show the evidence.
4
Evolve Deliver · measure · sustain

Deliver, measure, and decide what continues after your team's involvement ends.

Tool 4 · Delivery & Impact Scorecard ReviewRecurring: on track, or flagged for intervention.
The journey at a glance

Phases, tools, and gates on one map

The same arc as a single diagram — four phases, three tools spanning them, and the instructor gates with their pass / revise-and-return loops.

How IMPACT Works CANVAS · DESIGN · TEST · EVOLVE Four phases Four tools Every phase gated by evidence TOOLS Problem Discovery Canvas Solution Design Pilot Test Board Delivery & Impact Scorecard 1 CANVAS Understand the problem — and the people it affects. Talk to real users · source every claim 2 DESIGN Generate solutions, then filter them honestly. Desirable · Feasible · Viable filter 3 TEST Pilot the strongest idea with real people. Cheapest test in front of a real person 4 EVOLVE Deliver, measure, and decide what continues. → present at the national competition G1 GATE — reviewed with the instructor PASS ✓ → Design REVISE & RETURN ↺ A real user confirmed the problem. Every claim is sourced. revise & return G2 GATE — reviewed with the instructor PASS ✓ → Test REVISE & RETURN ↺ Tested with real people. Evidence shown, not impressions. revise & return RECURRING MILESTONE REVIEW — repeats through Evolve, not just at the end ON TRACK → continue NEEDS INTERVENTION ↺ The rule that makes the gates work A team clears a gate by defending its evidence — not by ticking boxes. Talk to real users first. Source every claim. Send the work back when the evidence isn’t there. ◇ instructor gate ↺ revise & return loop → proceed when evidence holds
Four tools, one arc

The tools you'll actually use

Each tool is a living document — not a form you fill in once. Return to it as your understanding deepens, your team changes, or your project pivots. A canvas that no longer reflects reality is worse than no canvas at all. Tap any tool to open it.

The foundation of your entire project. It forces you to separate what you assume from what you actually know — and to keep the person experiencing the problem at the center of everything. Complete the full canvas before any solution conversations.

The five sections

The Who

Name the specific, observable groups affected. "The community" is not specific enough.

The Problem

State it in one or two sentences — then challenge whether it's the real problem or a symptom.

Root Cause

Ask why until the answers stop being actionable. Five is a guide, not a magic number.

What's Been Tried

Find out what was attempted before — and why it didn't last.

Success (their view)

Define success from the user's perspective, not the team's deliverables.

Before you fill it in

Run a discovery conversation

Ask about the last time it happened — not hypotheticals. Listen far more than you talk; never pitch.

Evidence check

Every claim traces to an interview, observation, or document. No source means it's an assumption.

Gate 1 — Canvas · cleared with your instructor
  • We have had at least three conversations with people who experience this problem.
  • A real user heard our problem statement and confirmed, in their own words, that it is their problem.
  • Every key claim on the canvas is sourced — we can say how we know it.
  • Our problem statement has been revised at least once based on what we heard.
  • We can describe the root cause, not just the surface symptom.
  • We can describe success from the user's perspective, not just the team's.

Moves your team from "we understand the problem" to "we know what's worth testing" — without committing to anything yet. Its core principle: ideas are cheap; the goal here is breadth and honesty, not commitment.

Step 1 — Generate

Diverge first

List every possible solution. No filtering yet — wild ideas often lead to practical ones.

Filter — Desirable · Feasible · Viable

Score each idea

Yes / No / Uncertain on each. Only ideas that score "yes" on desirable move to testing.

Gate 2 — Design · cleared with your instructor
  • We have generated at least three distinct solution ideas.
  • We have applied the Desirable / Feasible / Viable filter honestly.
  • At least one idea scores "yes" on Desirable and is ready to test.
  • Our whole team was involved in generating and filtering.

A test is not the final product — it's the cheapest version of your idea you can put in front of a real person. The goal is to learn, not impress.

Common test methods

Paper prototype

Sketched version of a product, service, or process. Walk someone through it.

Role play

Act out the interaction. One team member plays the user.

Story test

Describe the solution as if it already exists. Ask: "Would you use this?"

Pilot session

Run one real instance of the solution with a small group.

Step 3 — Decide

Commit to one

Compare what you learned, rate your confidence, and pick one direction. Indecision is a decision to drift.

Gate 3 — Test · cleared with your instructor
  • We have tested at least one idea with real people in the community.
  • We set our success and failure thresholds before we ran the test, not after.
  • We can show the evidence from our test — notes, photos, data — not just our impression.
  • Our whole team agrees on the solution, and can explain why we chose it over the alternatives.

Your team's operating center during Evolve. It is not a report card — it is a steering wheel. Use it every week to know whether the project is on course, drifting, or heading somewhere it should not be.

Sprint Log

One-week cycles. Three to five specific tasks, one owner each. What you'll finish, then what actually happened.

Milestone Map

Major checkpoints written as completed outcomes, not process steps — with dates and owners.

Risk Register

What could go wrong, rated by likelihood and impact, with a mitigation. Updated every two weeks.

Impact Indicators

Outputs you produce vs. outcomes that change for people. Track both — never mistake one for the other.

Evolution & Sustainability

What changed since Canvas, and what has to be true for the impact to continue after your team leaves.

Gate 4 — Evolve · Milestone Review, run at each milestone
  • We run a sprint review every week — every member updates their task status.
  • Our milestone map is current; risks are updated at least every two weeks.
  • Our impact indicators are being tracked — we are collecting data, not just planning to.
  • We have shared an update with our community partner in the last two weeks.
  • We are ready to present what we learned — not just what we delivered.
  • We have named what has to be true for this project's impact to continue after us.
The rule that makes the gates work

You clear a gate with evidence — not optimism

A gate you pass on optimism is a gate that fails you later. Gates aren't self-checked. They're checkpoints your team walks through with the instructor, who is there to pressure-test your evidence — not to rubber-stamp it.

A team clears a gate by defending its evidence — not by ticking boxes. Talk to real users first. Source every claim. Send the work back when the evidence isn't there. If you can't defend an item out loud, you're not through the gate — and learning that now is the point.
01 · Show

Bring the evidence — conversations, a test result, a user's own words — not a feeling that you're ready.

02 · Defend

Walk the instructor through it out loud. If you can't, the gate isn't clear.

03 · Decide

Pass and proceed, or revise and return — recorded, with what must be true to pass.

Learn from the usual traps

Common mistakes — and what to do instead

Most community projects fail the same handful of ways. Name them now, and you can dodge them. Each card is a trap on the left and the fix on the right.

01

Jumping to solutions too early

Complete Tool 1 in full. Do not open Tool 2 until your canvas is finished and a real user has confirmed the problem.

02

Building before testing

Test the simplest version of your idea first. An untested solution is just a guess dressed up as a plan.

03

Tracking activity, not impact

Separate outputs from outcomes. Measure both, report both — and never mistake one for the other.

04

Assuming the team is aligned

Review the tools together. Alignment must be spoken, not assumed — surface disagreement early.

05

Avoiding bad news

Surface problems early. A blocked task is better caught in week two than week ten, when it's too late to fix.

06

Treating tools as paperwork

These tools are how the work gets done, not how you report on it after the fact.

Just beginning?

Start with Tool 1, Section 1 — The Who. Complete the full canvas before any solution work.

Problem already defined?

Move to Tool 2, Step 1 — Generate. Filter with Desirable / Feasible / Viable before testing.

Have a filtered idea, not yet tested?

Go to Tool 3, the Pilot Test Board. Run a real test before building anything further.

Already building or delivering?

Start with Tool 4, the Sprint Log or Impact Indicators — then backfill Tools 1–3 so the whole team shares context.

Annex A · Worked example

One community project, start to finish

All four tools, filled out for one fictional project — a financial literacy program for first-generation students — so you can see the standard to aim for. Watch three things: the team's thinking evolves as they learn, the entries stay specific, and each tool feeds the next.

ProjectBridgeReady
Focus areaFinancial literacy
CommunityRiverside High, 9th–10th grade
Team4 students (Lead + 3)
Tool 1 · Canvas

The problem wasn't apathy — it was never being taught

First-generation 9th and 10th graders at Riverside have part-time income but no bank account, no savings, and no understanding of credit. Five conversations reshaped the team's thinking: they assumed students did not care about money. They care deeply — they have simply never been taught. That changed how they framed the problem entirely, and pushed the root cause past "students weren't taught" to generational financial exclusion.

5 conversations before any solutionProblem statement revised after interviews
Tool 2 · Design

Three ideas generated, one filtered forward

A peer-led workshop series, a money-mentor app, and a family finance night. Against Desirable / Feasible / Viable, the workshop series scored strongest — students wanted a structured setting, the counselor confirmed a class slot, and it required no grant funding. The app was set aside for this semester; the family night survived as a possible companion, not the core mechanism.

3 ideas generatedFiltered to 1 primary + 1 companion
Tool 3 · Test

A 20-minute pilot confirmed the hypothesis

The team ran a 20-minute role-play test of the workshop with eight volunteer students, hypothesizing that content tied to real income would land better than hypothetical examples. Seven of eight completed the worksheet; six said they'd attend a full series; three brought up their own financial situations unprompted. The hypothesis held, and the team moved forward with confidence.

7 of 8 completed the worksheet6 would attend a full seriesChose: peer-led workshop
Tool 4 · Evolve

A week-3 snapshot — including what went wrong, and who takes over

Mid-delivery, the scorecard isn't perfect — and that's the point. A blocked task (the counselor was out, freezing a room booking) sits in the same sprint log as the wins, escalated to the assistant principal. Across every impact indicator, the project is on track. And because the counselor's ongoing involvement was a single point of failure, the team began training a second staff member to co-facilitate — so the program can continue after the team's semester ends.

Avg 15.5 students / sessionRelevance 4.3 / 5Second facilitator being trained for handoff

What this example shows. The BridgeReady team did not start with a perfect plan. They revised their problem statement after the first interviews. They generated three ideas and filtered honestly before testing anything. They tested before building. And they logged a failure — the counselor absence — in the same sprint where they recorded their wins, then designed for who keeps the program running after they leave. That is exactly what good project management looks like: not a team that never gets blocked, but a team that sees problems early, names them clearly, and builds for what happens after they're gone. Use it as a standard to aim for — not a template to copy.