Bepaal de kosten voor de afdelingen (R&D, PS, CS, S&M) 

Bepaal de costs of goods sold 

Bepaal de Winner, Modest winner, Walking wounded & Wipe-out scenario’s. Wees niet te optimistisch over de adoptie, vergelijk het met de Innovatiecurve 

Betrek 3e partijen (wanneer relevant) in de BC 

Denk aan subsidies zoals WBSO 

Bepaal de doorontwikkeling per kwartaal op basis van de doorontwikkelingen die je hebt bepaald in de ontwikkeling van je prototype 

Leg de businesscase voor aan het MT voor een officiële GO/NO GO 

Ontdek welke soorten prijsstellingen er zijn 

Bepaal welke prijsstrategie je wil inzetten (à voorbeelden). Let op! De prijsstrategie heeft invloed op de binnendienst en sales, dus ga hier al met hen in gesprek.  

Stem af met MT 

Toets bij klanten 

Betrek een development team of architect erbij. Als je zelf geen PO bent, contacteer dan de innovatiemanager. Hij/zij kan in overleg bepalen met welke PO jij contact kan opnemen.  

Leg de requirements voor aan development team en/of architect en laat hen een ontwikkelinspanning inschatten 

Schrijf requirements op, op basis van je toetsing van het idee, denk niet alleen aan functionele requirements, maar ook al niet-functionele requirements à uitstapje naar voorbeelden (paraplu IREB). Vergeet de requirements van de externe partij niet wanneer relevant! Requirements.pdf. Start met de SRS om deze requirements in vast te leggen.  

Betrek de UX designer en laat een design maken van jouw idee. Dit design gebruik je om bij klanten te toetsen.  

Bepaal wat binnen de MVP valt door te toetsen bij klanten, maar ook intern toetsen kan van waarde zijn.  

Wat valt buiten de MVP en wat wordt doorontwikkeling 

Zie je risico’s voor de toekomst, leg deze vast voor jezelf (deze risico’s moeten afgehandeld worden via het P20 Riskmanagement proces)  

Toets het MVP opnieuw (en laat de designs updaten door de UX designer) 

Bij een koppeling of integratie, contact de externe partij om  technische requirements af te stemmen. Spreek met hen ook de scope van de MVP af. 

Verfijn je requirements op basis van de toetsing met klanten, interne collega’s en externe partijen (wanneer relevant).  

Let op! Go/No Go moment op basis van de analyse. Als het idee niet goed valt bij klanten, bepaal dan ook of je opnieuw naar de tekentafel gaat of je het onderzoek stopt. Stem dit af met je manager en innovatiemanager.  

Wat doen concurrenten? 

Zijn er soort gelijke producten op de markt die bewezen werken? (check ook binnen TSS) 

Zijn er externe partijen die kunnen bijdragen aan de oplossing?  

Bepaal ook logging requirements (bijvoorbeeld performance, responstijd, foutmeldingen, etc.)  met interne stakeholders en bouw deze in. De logging gaat richting geven wanneer er mogelijk problemen ontstaan in productie. Tools zoals dashboarding kunnen je helpen om de adoptie te kunnen meten.  

Zodra je op ongeveer ¾ van de ontwikkeling  van je MVP bent, start met marketing om een marketing plan te maken zodat je voorbereid bent voor de uitrol. (Tijdspad Marketing en Redactie - Nieuw feature - Module.docx) Tip! Je kan erover denken om webinars of gratis presentaties te organiseren, zodat klanten zich kunnen inschrijven en vragen kunnen stellen. Het doel is om de adoptie te verhogen. Neem dit mee in het marketingplan en denk creatief.  

Schrijf een handleiding over de MVP. Deze kun je met de pilotgebruikers delen zodra zij beginnen met testen. Stem hierbij met Redactie af over het format en de styling (bijvoorbeeld Handleiding_Snelteksten.V2.docx) 

Werk je met externe integraties, bedenk dan of een pentest benodigd is. Overleg met Kwaliteit over de kaders. Zorg dat de pentest is uitgevoerd voordat je in pilot gaat, zodat eventuele security risks voorkomen kunnen worden.  

Als je initiatief tegen betaling wordt verkocht, ga dan samen met de binnendienst aan de slag om het implementatie- en facturatieproces tot stand te brengen. Verdeel rollen en verantwoordelijkheden.  

Zoek de samenwerking op met een PO & ontwikkelteam (als product champion geen PO is) die gecommitteerd kan werken aan het nieuw initiatief. 

Werk met een PO samen om de SRS op te stellen, deze zal de basis zijn voor het ontwikkelteam.  

Het ontwikkelteam en de architect zullen naar de technische requirements kijken en deze vastleggen in de AD/SRS/SRS sec/SRS BNF/DD.  

Stel samen op basis van de requirements uit de SIG de stories op in Jira. 

Op basis van de geschreven stories ontstaat een backlog die je samen met het team prioriteert, wat wordt eerst opgepakt en wat kan later.  

Refine samen de stories tijdens de refinement, dit is het moment om samen zowel functioneel als technisch te kijken of dit daadwerkelijk overeenkomt met input uit de SIG.  

Ontstaan er vragen vanuit het ontwikkelteam, neem deze dan terug mee naar de SIG.  

Werk toe naar een MVP, let daarbij op dat de P20 documentatie up to date wordt gehouden.  

Bepaal samen geschikte tijd, plaats, manier van ontmoeten, etc.  

Jij bent de initiatief nemer, dus zorg ook dat de SIG’s tijdig zijn gepland en goed georganiseerd zijn. 

Geef de SIG structuur door eerst terug te kijken wat er is ontwikkeld op basis van de vorige SIG en kijk het tweede gedeelte van de SIG vooruit. Leg je doel vast voor de volgende SIG.  

Maak duidelijke afspraken over de werkwijze die jullie gaan gebruiken om tot de MVP te komen en leg dit vast in notulen. Bijvoorbeeld: volgordelijkheid features, wat valt er wel binnen de scope, wat valt er buiten de scope, etc.