De bästa och sämsta sätten att skapa en produktspecifikation

En av de största utmaningarna för produktutvecklingsteam är helt enkelt hur de ska bestämma vilken produkt de ska bygga. När det gäller team som arbetar utifrån en produktspecifikation, särskilt inom hårdvaruutveckling, får ingenjörerna vanligtvis inte börja arbeta förrän den är färdigställd och godkänd. Och med tanke på att de flesta utvecklingstidtabeller är otroligt korta finns det ofta inte tillräckligt med tid för att överväga alternativa lösningar när ny information dyker upp.

Ett sätt att se på denna utmaning visas här. Du kan föreställa dig att cirkeln är alla möjliga sätt som teamet kan bygga produkten på. Och den lilla blå pricken är specifikationen för en viss produkt. Denna produktspecifikation definierar exakt vilken produkt som utvecklarna ska fokusera på och bygga.

I det här inlägget ska jag först beskriva några av de vanligaste metoderna som används för att komma överens om en produktspecifikation. Sedan kommer jag att utforska problemen med dessa metoder och hur de kan leda till att man bygger produkter utifrån en specifikation som faktiskt inte löser kundens problem.

Jag bör säga att mitt perspektiv kommer från 10 års erfarenhet av att arbeta inom den analoga och blandade signalhalvledarindustrin, först som applikationsingenjör och senare som produktdefinierare. Nu är jag konsult här på Jama.

Svåraste sätten att skapa en produktspecifikation:

Fråga din kund vad de vill att du ska bygga

Ett sätt att börja är att fråga dina kunder vad de behöver. Detta kan göras genom att vänta på en offertförfrågan (RFQ) som utfärdas av kunden, eller mindre formellt genom möten och diskussioner. Det du vanligtvis får veta med denna metod är vilken lösning eller produkt de använder i dag och vad de skulle vilja se förändras inom en mycket snar framtid. På sätt och vis agerar du som en entreprenör och kunden ansvarar för alla detaljer i specifikationen.

Med tanke på att det här scenariot kräver att man itererar på en befintlig produkt är sannolikheten stor att du kommer att sluta med en mycket specifik idé som du definitivt kan genomföra.

Det finns dock flera problem med detta tillvägagångssätt:

Det som din kund berättar för dig om sin produktstrategi berättar de troligen också för dina konkurrenter, och ett viktigt mål med projektet är troligen att göra något billigare än den befintliga lösningen. Du kommer att hamna i ett priskrig.
Din kund är redan inställd på en typ av lösning, baserat på vad de har köpt tidigare, vilket gör det svårt att föreslå något som kanske bättre uppfyller deras behov.
Tidsplanen är troligen extremt aggressiv, vilket ger små möjligheter att bygga något nytt eller tillåta verklig innovation.
Din kund är kanske inte medveten om ny teknik, eller så vet han eller hon helt enkelt inte vad han eller hon behöver.

I det här fallet förlitar du dig på att kunden ska översätta sina interna krav till en specifikation för dig, snarare än att du skriver krav för en produkt som den bredare marknaden behöver och kommer att köpa.

När du utvecklar produkten kommer ditt team oundvikligen att behöva göra avvägningar av olika skäl. Det enda sättet att vara säker på att det bästa valet görs är att se över ändringar av den resulterande produktspecifikationen med din kund. Om du inte gör det riskerar du att bygga en produkt som de inte kommer att acceptera. Men eftersom konstruktionsteamet kommer att stå under extrem press för att genomföra ett aggressivt tidsschema finns det en stor chans att de kommer att göra produktval utan att ha tillgång till all den bästa informationen. Detta ökar ytterligare risken för att bygga fel produkt.

Detta tillvägagångssätt fungerar genom att en produkt levereras. Om du arbetar med att leverera standardkomponenter är detta bra. Om du letar efter en unik lösning som försvarar bruttomarginalen är detta inte det bästa tillvägagångssättet.

RELATERAD POST: 2. Låt en ingenjör skriva hela specifikationen

Ett annat vanligt scenario är det där en ingenjör, eller någon annan medlem av teamet med kundkontakt, tänker sig en lösning baserad på samtal som de har haft med en eller ett fåtal kunder. Teamet samlas kring den här idén, och med ett internt momentum dokumenteras kraven snabbt och teamets arbete går snabbt över till att skriva produktspecifikationerna och utveckla lösningen.

När lösningen är färdig och redo att lanseras på marknaden validerar en del team sin idé med kunderna, men eftersom teamet presenterar en lösning – och inte utforskar ett behov – tenderar diskussionen att handla om detaljerna i produktspecifikationen. Dessa team har inte möjlighet att ta reda på om lösningen löser ett problem.

Typiskt för det här scenariot är att produktkraven kommer direkt från en individs huvud och sedan fångas upp i ett omfattande specifikationsblad, och resten av teamet använder sig av den dokumenterade specifikationen. Varje gång teamet stöter på en konflikt där en avvägning måste göras, måste den person som skrev kraven besluta om de korrekta avvägningarna självständigt, med lite eller ingen ny information. Om den personen dessutom inte har undersökt eller validerat kraven kommer teamet att bygga fel produkt.

Varför dessa tillvägagångssätt inte leder till framgång

Vad båda de tidigare tillvägagångssätten har gemensamt är att fokus ligger på att få fram en färdig produktspecifikation så snabbt som möjligt. Teamen har så bråttom att börja bygga något och hålla kundens deadline att de inte först ser till att något är rätt något.

Det är dessutom så att kunskapen om kraven finns hos bara en person i teamet. Den individen är antingen den person som har kontakt med sponsorkunden, eller så är det den person som kom med produktidén. I båda fallen saknar resten av teamet ett sammanhang för lösningen, varför de bygger den här produkten, och kan därför inte ge rekommendationer.

Resultatet blir ofta att produkter dödas senare än de borde ha gjort, efter att mycket tid och pengar har slösats bort, eller så skapar teamet produkter som är misslyckade eller me-too produkter som till stor del konkurrerar på priset. Inget av detta är bra för affärsverksamheten.

RELATERAD POST: 8 Do’s and Don’ts for Writing Requirements

De bästa sätten att skapa en produktspecifikation:

Det bästa sättet att skapa produkter som dina kunder kommer att köpa är att gå ut och prata med din målgrupp långt innan du börjar skriva din specifikation. Först måste du formulera din problembeskrivning.

En problembeskrivning för en produkt är några meningar eller stycken som beskriver ett marknadsbehov. De är skrivna ur perspektivet för den persona som har problemet och – detta är avgörande – säger ingenting om hur man faktiskt löser problemet. Målet med detta steg i utforskningen är att förmedla en förståelse för problemet och en känsla av det värde som är förknippat med att lösa det.

En problembeskrivning består i allmänhet av tre delar:

Den första är persona, eller en beskrivning av vem som har problemet. Det är bra att beskriva persona i detalj separat och sedan hänvisa till en viss persona i problemformuleringen för att undvika att upprepa samma personabeskrivning.
Nästan är det en beskrivning av problemet. Ju mer detaljerat desto bättre här. Du vill försäkra dig om att behovet är kristallklart. Ge också problemet ett namn. Det gör det lättare för teamen att hänvisa till det under projektets gång.
Slutligt skriver du en beskrivning av hur ofta problemet uppstår. Om problemet inträffar sällan och har liten inverkan är det av lågt värde att lösa det. Om problemet inträffar ofta och har stor inverkan är värdet av att lösa det högt.

Du kan börja med att fråga kunderna vilka problem de har som de tror att du kan lösa, men du måste gräva djupare för att komma fram till de verkligt värdefulla problemformuleringarna eller guldklimparna. Dessa gyllene guldkorn kommer i allmänhet från att utveckla en djup förståelse för marknaden och sätta ihop information från en mängd olika källor.

Om du gör detta framgångsrikt kommer du till slut att identifiera ett problem som du kan lösa och som din kund kommer att betala för.

Under processen ska du vara försiktig så att du inte stöter på falskt positiva eller negativa problem. Om du lyssnar för mycket på personer inom ditt företag eller bara på ett litet antal kunder kan det leda till att du felaktigt bekräftar eller överger ett problem. Prata med så många kunder som möjligt och samla in så mycket data som möjligt.

Vi går tillbaka till vårt diagram över alla möjliga produkter som vi kan bygga.

Den här gången har vi lagt till korsande linjer som representerar begränsningar. Om vi tänker oss problemformuleringar som linjer som korsar cirkeln, kommer en bra problemformulering som bygger på marknadsförståelse att avgränsa ett område i cirkeln som representerar alla acceptabla lösningar. Allt inom detta område löser problemet och skulle vara acceptabelt för kunden.

Du kommer att märka att storleken på detta område är mycket större än de tidigare cirklarna för förfrågningsunderlag och produktidéer. Detta beror på att dessa problemformuleringar och sammanhang avsiktligt binder lösningen så löst som möjligt för att möjliggöra för nya idéer att komma fram.

Tanken är att ge designteamet maximal flexibilitet för att skapa den mest innovativa lösningen som är möjlig inom ramen för begränsningarna.

RELATERAT POST: Checklista:

Hur får man fram en slutgiltig problembeskrivning?

Här är mina rekommendationer:

Start med att tilldela någon för varje projekt ansvaret att vara kundens röst.
Därefter bör du ge den personen i uppdrag att identifiera marknadsproblemen enbart baserat på information som samlats in från marknaden.
Säkerställ att dessa marknadsproblem dokumenteras och delas på en plats som hela teamet har tillgång till.
Skriv ner en motivering för varje marknadsproblemutlåtande som förklarar varför det är ett problem och hur viktigt det är att lösa
Inför en milstolpe i projektplanen där problemutlåtandena måste granskas och godkännas av teamet tillsammans med ett business case.
När teamet börjar utveckla en lösning, återkommer du regelbundet till listan över problembeskrivningar för att påminna alla om vad målet är.
För varje problem ska du fånga upp en lista över de produktfunktioner som kommer att lösa problemet.
Om något problem inte kan lösas helt och hållet, se över affärsidén på nytt för att se till att produkten fortfarande är gångbar.

Från problembeskrivning till specifikation

När du nu har dina problembeskrivningar och teamet har bekantat sig med dem, kan du börja utveckla en produktspecifikation i samarbete. Eftersom alla i teamet förstår det problem som ska lösas kan alla bidra till specifikationen.

Då du har gjort det inledande arbetet med att identifiera det problem som du ska lösa, inom identifierade begränsningar, och ditt team har övervägt flera olika sätt att leverera lösningen, har du tillräckligt med information för att skriva produktspecifikationen.

Släpp produktspecifikationen i små delar

Det bästa tillvägagångssättet här är att släppa små delar av specifikationen till teamet så tidigt som möjligt för att få snabb feedback. På så sätt undviker du att slösa tid på fel väg och gör det mycket lättare för teamet att ge feedback av hög kvalitet.

Inte övertygad? Tänk på det här: Vad händer om du får ett 200-sidigt specifikationsblad att granska? Du tittar förmodligen på de första sidorna och skummar sedan resten.

Vad händer om du får ett dokument på en sida? Du går förmodligen igenom hela dokumentet. Tvåhundra ensidiga dokument ger mycket bättre feedback än ett enda 200-sidigt dokument.

Hänvisa till problemformuleringen för att försäkra dig om att du är på rätt spår

Också, när du utvecklar specifikationen, kolla tillbaka för att försäkra dig om att produkten fortfarande är en giltig lösning på problemet. Det är lätt att fastna i den avvägning som är inneboende i utvecklingen av en produkt och glömma att kontrollera om du fortfarande är på rätt spår.

Detta tillvägagångssätt hanterar också förväntningarna hos dina intressenter. Eftersom processen är kontrollerad finns det en ram och öppenhet som förhindrar att någon åsidosätter besluten. När som helst i projektet kan du förklara exakt vilket värde din produkt erbjuder och varför den måste ha de funktioner som teamet har specificerat.

Design av produkter för marknadens behov är avgörande för framgång

Jag inser att i vissa branscher är detta en stor förändring från hur produkter har designats och byggts. Men i takt med att marknaderna blir mer konkurrensutsatta och produkterna blir alltmer komplexa kommer det inte att räcka med att bara leverera ytterligare en iteration av något som du har byggt tidigare för att hålla dig kvar i branschen länge.

För att lära dig mer om hur du skriver krav på ett sätt som gör att alla intressenter får en tydlig förståelse för utvecklingsbehoven, kan du ladda ner vår e-bok, Best Practices for Writing Requirements.

LÄS EBOKEN