Design Sprint [by Jobresponse]

What is Design Sprint?

The Product Discovery phase is a form of a well-known design sprint (introduced by Google fellows) with just slightly different goals. The discovery phase intends to get enough product specifications for the first development phase. It generally follows a lean approach so that the specification is just sufficient to get the product from 0 to 1. The discovery phase does not include the full set of requirements, nor does it test any business hypotheses, product-market fit, or perform customer development — it’s product-wise.

Before building software, it’s essential to ensure the product requirements are understood well by all stakeholders. Ensuring the team is on the same page concerning the product specification, deliverables, timelines, and budget is vital. Moreover, this leads to better communication and a higher project success rate.

There is a wide range of design sprint variations, and it may be configured depending on the project type and its goals. Some vendors set out a full set of product specifications that is excessive for MVPs. For example, if your idea is Uber for X, a vendor may come up with requirements that are normally found in that product niche. But those products may have already been for a decade on the market, have rich feature lists, complicated architecture designs, and tens of thousands of users. An MVP doesn’t need all that and thus may need more of a lean approach.

Design Sprint is the best way to start the project. In fact, the more of the smaller steps you do, the higher chance of the project's success. Even the main phase of software product development is broken into pieces of weekly or bi-weekly iterations.

How does the process look?

Once you reach an agreement with a vendor to work on the design sprint, you’re now set to a pilot project with the partner and can test some assumptions about working with the team.

During the design sprint, the team works on particular topics to research the product requirements, available examples, the product's technical feasibility, third-party services’ compatibility, and creates tests and project specs.

Depending on the complexity, the team configuration may range. Again, some vendors may allocate a flock of highly skilled individuals that may be excessive for the product. Discussing the team configuration, timeline, and budget is safer on the shore.

The full team configuration may include:

• Product Manager
• Backend Engineer
• Frontend/Mobile Engineer
• UI/UX Designer
• CTO
• Business Analyst
• Project Manager
• QA

But your MVP design sprint team may actually look different and include only three team members:

• Project Manager
• Backend Engineer
• UI/UX Designer

Yes, for large enterprise software projects, you’ll need everyone to contribute to the research phase, but MVP does not require the same effort. Its goal — is a short go-to-market timeline, whereas enterprises are always drowned in the long and expensive processes, which is good for them but not for a brand new startup.

As the team completes the discovery phase, the results of the iterations may include but are not limited to:

• Main use cases diagram
• User story maps
• UI examples, mockups, clickable prototypes
• MVP Scope of Work [by Jobresponse], detailing the implementation, as well as questions, issues to consider as well as potential solutions
• Feature list
• Lists and details of the third-party services and APIs
• Tech stack details
• Data structures
• Assumptions
• Team configuration for the development phase
• Estimated timeframe and budget approximations
• Preliminary weekly plan

At the end of the design sprint, the project is equipped with everything you need to make an informed decision. Moreover, you also have a sense of what working with the team looks like.

Timeline

The design sprint, like every other iteration during the development phase, most of the time lasts one or two weeks for MVP. The only difference is that this stage is an initial stage that defines how the rest of the project goes.