Föreställ dig detta: Du är tre veckor in i utvecklingen. Designern visar dig en mockup. Du stirrar på den, förvirrad.
“Vänta,” säger du, “jag trodde vi byggde detta för företagskunder.”
“Nej,” svarar designern, “vi riktar oss till ensamma utvecklare. Därför är allt nedstrippat.”
Samtidigt kommer produkt in: “Varför är inte detta multi-tenant? Vi behöver teamarbetsytor.”
Alla byggde vad de trodde produkten skulle vara. Ingen samordnade om vad den faktiskt är. Nu är ni tre veckor in och inser att ni har byggt tre olika visioner av samma app.
Detta är det dyraste misstaget i mjukvaruutveckling. Inte buggar. Inte teknisk skuld. Felaktig samordning. När team inte delar samma förståelse av vision, mål och intressenter bygger de fel sak—effektivt.
Lösningen? Canvas-tänkande. Sex lättviktiga filer som besvarar de strategiska frågorna innan du skriver en enda kodrad.
Problemet: Bygga i olika riktningar
Här är hur felaktig samordning sker:
Produkt läser TRD:n och tänker: “Vi bygger för företagsteam som behöver samarbete och compliance.”
Design läser samma TRD och tänker: “Vi bygger för ensamma utvecklare som behöver hastighet och enkelhet.”
Engineering tittar på tekniska begränsningar och tänker: “Vi bygger en API-first-plattform som vem som helst kan integrera.”
Alla tre bygger baserat på antaganden de aldrig bekräftade med varandra. TRD:n definierade vad som skulle byggas, men den klargjorde inte den strategiska kontexten: Vem är detta för? Vilket problem löser vi verkligen? Vad ser framgång ut som? Vad är vi osäkra på?
Det är där canvas kommer in.
Vad är en canvas?
En canvas är ett strukturerat sätt att fånga strategisk kontext i sex enkla filer:
- vision.md — Var är vi på väg om 12 månader?
- goals.md — Vad mäter vi? (SMART-mål)
- stakeholders.md — Vem gynnas? Vem köper? Vem bygger?
- questions.md — Vad vet vi inte? Vad är osäkert?
- ideas.md — Brainstorming och inspiration
- notes.md — Observationer och lärdomar
Varje fil är 10-30 rader. Total tid att fylla: 30 minuter. Total felaktig samordning förhindrad: veckor av slösat arbete.
Canvas sitter mellan din TRD och din plan. TRD säger vad du bygger. Canvas säger varför, för vem, och med vilka okända faktorer. Sedan extraherar du en plan.
Djupdykning: De sex canvas-filerna
1. vision.md — Var är vi på väg?
Vision besvarar 12-månadersfrågan: Om detta projekt lyckas, vad kommer vara sant som inte är sant nu?
Dålig vision (för vag):
# Vision
Bygg en fantastisk produkt som användare älskar och som tjänar pengar.
Bra vision (specifik, testbar):
# Vision
## Syfte
Bli standardautentiseringsleverantören för indie SaaS-utvecklare som vill ha GDPR-kompatibel auth utan att hantera OAuth-infrastruktur.
## Framgångssignaler
- 500 aktiva utvecklare som använder tjänsten
- 10k autentiseringsförfrågningar/dag
- Featured i "awesome-saas-tools"-listor
- NPS >50
## Icke-mål
- Riktar oss inte till företag (inget SSO, inga compliance-certifieringar)
- Bygger inte en dashboard för användarhantering
- Konkurrerar inte med Auth0/Okta på funktioner
Lägg märke till: specifikt användarsegment, mätbara utfall, explicita icke-mål. Detta förhindrar scope creep och håller alla samordnade på målet.
2. goals.md — Vad mäter vi?
Mål är SMART-mål med tidsramar. De besvarar: Hur vet vi om vi lyckas?
Dåliga mål (vaga, omätbara):
# Mål
- Bygg ett snabbt auth-system
- Få användare
- Gör det säkert
Bra mål (SMART: Specifika, Mätbara, Uppnåeliga, Relevanta, Tidsbundna):
# Mål
## Kortsiktigt (4 veckor)
- Slutför email/password-registreringsflöde med <300ms svarstid (p95)
- Klara OWASP-säkerhetchecklistan för autentisering
- Deploya till produktion med 99,9% upptids-SLA
## Medellångsiktigt (12 veckor)
- Nå 100 aktiva utvecklare som använder tjänsten
- Stöd för 5k autentiseringsförfrågningar/dag med <1% felfrekvens
- Publicera API-dokumentation och 3 integreringshandledningar
## Långsiktigt (6 månader)
- Uppnå 500 aktiva utvecklare
- Generera 2k SEK MRR från premiumtier
- Etablera partnerskap med 3 indie SaaS-communities
Nu vet alla vad framgång ser ut som i varje steg. Inga gissningar. Inget “Jag trodde vi syftade till…“
3. stakeholders.md — Vem bryr sig?
Stakeholders besvarar: Vem gynnas? Vem betalar? Vem bygger? Vem godkänner?
Detta är den mest förbisedda filen—och den mest kritiska. Missförstånd om intressenter betyder att bygga för fel publik.
Exempel:
# Intressenter
## Primära användare
- Indie SaaS-utvecklare (1-3 personsteam)
- Tekniska grundare utan säkerhetsexpertis
- Utvecklare som migrerar från Firebase Auth
Förväntningar: Snabb installation (<30 min), tydliga dokument, inga överraskningar i prissättning
## Sekundära användare
- Slutanvändare som loggar in på appar byggda med vår tjänst
- De vet inte att vi existerar (white-label)
## Beslutsfattare
- Tekniska grundare (väljer auth-leverantör)
- Utvärderar på: enkelhet i integration, compliance, kostnad
## Internt team
- Engineering: 2 utvecklare (backend-fokus)
- Produkt: Grundare (deltid)
- Support: Initialt grundare, senare konsult
## Externa begränsningar
- Måste uppfylla GDPR-krav (juridiskt)
- Måste integreras med Stripe (betalningar)
Nu vet design att inte bygga komplexa admin-dashboards (användare är tekniska). Produkt vet att prissättning måste vara transparent (grundare utvärderar på kostnad). Engineering vet att prioritera dokument (snabb installation är nyckeln).
4. questions.md — Vad vet vi inte?
Detta är den mest kraftfulla filen i canvas. Den fångar osäkerhet—sakerna du behöver forska, testa eller bestämma innan du kan bygga med förtroende.
Exempel:
# Öppna frågor
## Användarbeteende
- F1: Föredrar utvecklare OAuth (Google/GitHub) eller email/password för sina slutanvändare?
- Forskning: Undersök 50 indie-devs, analysera auth-mönster i populära verktyg
- F2: Kommer användare acceptera 24-timmars sessionutgång, eller förväntar de sig "kom ihåg mig" i 30 dagar?
- Forskning: Konkurrennsanalys, användartestning
## Tekniskt
- F3: Kan vi hantera 10k samtidiga sessioner på en enda $50/månad-server, eller behöver vi load balancing?
- Forskning: Lasttestning, benchmarka Postgres connection pooling
- F4: Ska JWT-tokens lagras i localStorage (XSS-risk) eller httpOnly cookies (CSRF-risk)?
- Beslut: Utvärdera avvägningar, välj en, dokumentera i ADR
## Affärsmässigt
- F5: Vilken prissättningsmodell fungerar för indie-devs—betala-per-användare eller platt månadskostnad?
- Forskning: Testa prissida med 3 alternativ, spåra konverteringsfrekvenser
Varje fråga blir en forskningsuppgift eller beslutspunkt. När någon frågar “Har vi bestämt XYZ?” kollar du denna fil. Om den inte finns där, lägg till den.
5. ideas.md — Brainstorma utan att förbinda
Ideas är din parkeringsplats för “skulle det inte vara coolt om…”-tankar. Det förhindrar avspårning utan att döda kreativitet.
Exempel:
# Idéer
## Funktioner (inte förbundna)
- Magic link-inloggning (lösenordslös)
- Biometrisk autentisering (Face ID/Touch ID)
- Social inloggning utöver Google/GitHub (Twitter, LinkedIn)
- Auditlogg för alla auth-händelser
## Tillväxttaktiker
- Lansera på Product Hunt med "GDPR-kompatibel auth på 30 min"-vinkel
- Skriv fallstudier med tidiga användare
- Bygg Wordpress-plugin för indie-bloggare
## Framtida utforskning
- White-label admin dashboard (ta betalt för premiumtier)
- Zapier-integration för automatiseringsarbetsflöden
När någon säger “vi borde lägga till Twitter-inloggning!” svarar du: “Bra idé—låt oss lägga till den i ideas.md och återbesöka i Fas 2.” Nu har du bekräftat idén utan att förbinda dig till scope creep.
6. notes.md — Fånga lärdomar
Notes är för observationer, insikter och kontext som inte passar någon annanstans. Den växer när du lär dig.
Exempel:
# Anteckningar
## 2026-02-15: Användarforskningsinsikter
- Intervjuade 12 indie-utvecklare. 9/12 föredrar OAuth över email/password för sina användare.
- Huvudsaklig oro: "Jag vill inte lagra lösenord och hantera intrång."
- Prissättning: Föredrar platt månadskostnad över per-användare-prissättning (förutsägbara kostnader).
## 2026-02-20: Teknisk upptäckt
- Postgres connection pooling med pgBouncer hanterar 5k samtidiga sessioner enkelt.
- JWT i httpOnly cookies + SameSite=Strict förhindrar CSRF utan XSS-risk.
- Bestämde att använda RS256-signering (ADR-003).
## 2026-03-01: Konkurrensanalys
- Auth0: För dyrt för indie-devs (23 USD/månad minimum).
- Firebase Auth: Enkelt men vendor lock-in-oro.
- Supabase Auth: Populärt men saknar avancerad RBAC.
- Möjlighet: Positionera som "GDPR-first"-alternativ.
Sex månader senare frågar någon “Varför valde vi RS256 över HS256?” Du kollar notes, ser datumet, länka till ADR:n. Kontext bevarad.
Hur canvas förhindrar felaktig samordning (ett verkligt exempel)
Låt oss säga att du bygger ett projektledningsverktyg. Här är hur canvas förhindrar katastrof:
Utan canvas:
- Designer bygger ett minimalt UI för ensamma användare
- Engineer bygger multi-tenant-arkitektur för team
- Produkt pitchar företagsfunktioner till investerare
- Tre veckor in: “Vänta, vem är detta ens för?”
Med canvas: Du fyller i stakeholders.md först och upptäcker:
- Primära användare: Små team (5-10 personer), inte ensamma användare, inte företag
- Beslutsfattare: Teamledare som utvärderar på samarbetsfunktioner
- Nyckelb begränsning: Måste integreras med Slack och Asana
Nu:
- Designer vet att optimera för teamarbetsflöden, inte ensam användning
- Engineer vet att multi-tenant är korrekt arkitektur
- Produkt vet att betona samarbete i marknadsföring, inte företagscompliance
Alla bygger samma produkt eftersom de jobbar från samma canvas.
Hur man fyller i canvas (30-minutersövning)
Steg 1: Börja med vision.md (10 minuter)
Besvara dessa frågor:
- Om detta projekt lyckas om 12 månader, vad kommer vara sant?
- Vem kommer använda det?
- Vad kommer de kunna göra som de inte kan nu?
- Vad försöker vi INTE göra?
Steg 2: Utkast goals.md (10 minuter)
Välj 3-5 mätbara utfall för varje tidsram (kort/medel/lång-sikt):
- Använd siffror: “100 användare” inte “massa användare”
- Lägg till deadlines: “senast vecka 12” inte “snart”
- Gör dem testbara: “95% upptid” inte “pålitlig”
Steg 3: Kartlägg stakeholders.md (5 minuter)
Lista alla som rör projektet:
- Vem använder det?
- Vem betalar för det?
- Vem godkänner beslut?
- Vad förväntar de sig?
Steg 4: Fånga questions.md (5 minuter)
Skriv ner allt du är osäker på:
- Användarbeteende du behöver forska
- Tekniska beslut du inte tagit ännu
- Affärsantaganden du behöver testa
Ideas och notes kan börja tomma—de fyller på när du jobbar.
När man ska återbesöka canvas
Canvas är inte skriv-en-gång-och-glöm. Återbesök den när:
- Stora beslut sker: Uppdatera notes med beslutet och varför
- Scope förändras: Flytta objekt från ideas till plan, uppdatera vision vid behov
- Användarforskning slutförs: Besvara frågor, justera mål baserat på fynd
- Milstolpar nås: Kolla om framgångssignaler från vision.md är sanna
Canvas är ett levande dokument. Håll det levande.
Varför detta spelar större roll än kodkvalitet
Du kan skriva perfekt kod för fel produkt. Du kan inte skeppa en värdefull produkt om ditt team bygger i olika riktningar.
Canvas-samordning förhindrar:
- Slösade sprinter med att bygga fel funktioner
- Design/engineering-konflikter (“Detta är inte vad jag designade!”)
- Intressentöverraskningar (“Jag trodde vi riktade oss till företag?”)
- Funktionsuppblåsthet (allt går i ideas.md först)
Canvas-samordning möjliggör:
- Snabbare beslut (kolla vision för nordstjärna)
- Tydlig prioritering (mål definierar framgång)
- Självsäkra planering (frågor dyker upp innan de spårar ur dig)
Det är 30 minuters samordning som sparar veckor av omarbete.
Prova det med ditt team
Välj ditt nuvarande projekt. Boka 30 minuter med ditt team. Fyll i canvas tillsammans:
- vision.md: Var är vi på väg? Vad är utanför scope?
- goals.md: Hur mäter vi framgång vid 4 veckor, 12 veckor, 6 månader?
- stakeholders.md: Vem bygger vi för? Vad förväntar de sig?
- questions.md: Vad vet vi inte ännu?
Fråga sedan: “Upptäckte vi just någon felaktig samordning?”
Chansen är stor att du hittar minst en sak där teammedlemmar hade olika antaganden. Fixa det nu, innan det blir tre veckors slösat arbete.
Kommer i Del 4: Från backlog till klart: Spåra verklig framsteg — Lär dig hur man översätter canvas + plan till handlingsbara backlog-objekt med acceptanskriterier, och hur status.md håller dig ärlig om vad som faktiskt blir gjort.
Nyckelord: projektcanvas, strategisk samordning, teamsamarbete, projektvision, intressentkartläggning, kravsamordning