What happens after a design sprint workshop for start-ups? 

You’re thinking about buying a Design Sprint workshop to kick-start the solution to your biggest problem. But you know a Design Sprint is just the first step in a longer process and that more work will come out of the back of it. 

What is that work, exactly, and what is the path to turning initial work into a market-ready product? 

This blog will discuss what happens after a start-up completes a Design Sprint workshop and has decided to progress with the development of the project. 

Iteration workshops 

With a decision made to move forwards with development, the next stage will often be a series of follow-up workshops, sometimes called iteration workshops. These are similar to a Design Sprint proper but take much less time. The team already knows each other, the problem is well defined, and the solution is starting to take shape. 

Iteration workshops allow teams to fine-tune aspects of the solution, build new prototypes, and gather additional testing data. A design team will normally ask back their original testers as their familiarity with the prototype product provides an advantage.  

When testing a prototype, even negative feedback is useful as it can be used to refer to further along the development process. And on the other hand, even with a positive overall response, further clarifications of assumptions are needed.  

Code Sprints  

Similar to an iteration workshop is a Code Sprint, which brings together a coding team to test out options in terms of architecture, infrastructure, frameworks, and libraries. The intention is to provide great certainty around development feasibility and possibility. The team works intensively to build a number of functioning prototypes in a few days. Application architects, data scientists, engineers, and product managers 

Polish the prototype

During this stage, start-ups focus on making high fidelity versions of the initial prototype created during the Design Sprint workshop. Though this version of the prototype does not need to be working software, it does, however, need to look and have the usability of a finished product.  

You may also show the new version of the prototype to more users to gain feedback. This will help you improve or many any necessary changes to it. A refined version of the initial prototype can also help strengthen the company’s internal momentum as it’ll keep up with the product’s new quality.  

Make a functional spec 

For software solutions, a team may turn the prototype into a functional spec document. A functional spec document will contain detailed user stories, assumptions about integration points, product roadmaps, budget estimates, and so on. 

Creating a functional spec document will help you create a structured outline of your game plan, increasing your chances of success. Oftentimes, teams focus on the grand vision of the product and demand higher budgets for product development. This can increase perceived/actual cost and risk. It may be a good idea to focus on your MVP first and ensuring it offers optimal UX.  

Determining timeline and budgets in advance can also help you identify future tradeoffs and gain clarity on costs of the product development process in the long term. Start-ups can consider getting estimates from external vendors. Often the internal team’s budget estimate is greater than the vendors’, and by choosing the latter, you might just end up saving money! 

MVP and beyond 

With a solid product basis in place, a team can proceed to MVP (minimum viable product) build-out. How a start-up decides to approach product development can vary. Some companies might just offer design services, but others, like Windmill, offer development services as well.  

An MVP is built incrementally according to Agile development practices. Product backlog, Sprint backlog, and product increment are the three main artefacts of Scrum. Product backlog contains all the features and functionality needed in the product; Sprint backlog is a backlog of features selected for a Sprint; and product increment shows the items completed in a Sprint. 

Windmill has found value in combining the product owner and Scrum Master roles. According to Sarika Kanade, ‘Product owner and scrum master should act as the main client/partner liaison and point of contact regarding the product definition and release roadmap. They should create constructive and positive relationships with the client using remote tools, working directly with clients to understand their business goals for the software and objectives for the product.’ 

Once the MVP is developed, it can be released and the team can continue work towards MMP (Minimum Marketable Product) and MMR (Minimum Marketable Release) stage. Work towards the final product will need the input of many teams, including the design, marketing, sales, finance, and testing teams. 

Conclusion 

Design Sprints must not be seen as standalone projects. Start-ups need to stay on track and not lose focus post the Design Sprint or the product development and launch process may suffer too. It’s also important to not lose motivation if the prototype created during the Sprint doesn’t receive positive feedback and take it as a learning lesson, as it can be a stepping stone to greater, higher quality products.    

Windmill offers market-leading design and build services that take an initial idea all the way through to final release. Find out how Windmill can solve your biggest product challenges today.