From brief to prototype in six hours: PD6 launches PdP projects

At Design Factory’s Product Development Project (PdP) course, students begin their two-semester journey with PD6, an intensive six-hour product development sprint. The day challenges multidisciplinary teams to turn a company brief into a prototype while learning to collaborate, ask better questions and make progress despite uncertainty.

“PD6 works as a catalyst. It pushes the student teams to make sense of their sponsoring company's brief, try out different frames, build excitement and adopt quick and dirty prototyping as an approach to problem solving. By the end of the day each team had built a prototype of an idea and gotten insights they didn't have in the morning of the sprint day,” explains PdP’s Coordinating Teacher Senni Kirjavainen.

PD6 method stemmed from the FutureLab research project, funded by Tekes in 2008.

“Based on our observations of the students’ behaviour, and on the information we had analysed about companies’ product development processes, it was clear that there was a need for this kind of approach. In a way, PD6 forces people to do things within a far too short timeframe, so that they produce results that would otherwise be almost impossible to achieve,” reflects Kalevi Ekman, the founding father of Design Factory and PdP.

A fast start to a long project

The PdP course brings students from different fields together to work on real-world product development challenges provided by sponsoring companies and organisations. PD6 gives teams a practical and energetic starting point for the work ahead.

The sprint helps students get to know their teammates, begin unpacking the challenge and use prototypes as tools for learning. They experience the pace and ambiguity of product development: making decisions with limited information, testing assumptions and moving forward without waiting for a perfect plan:

“PD6 helps the students and industry sponsors to kick off co-creation, moving away from the asking-and-answering dynamics that might easily prevail in the beginning of new project" PdP’s Course Professor Tua Björklund points out.

The aim is not to create a finished product in six hours. Instead, teams simulate the product development process by producing a tangible solution idea and learning how to approach the challenge.

From assumptions to questions

The day begins with each team creating a master plan. They define how to use their time, assign responsibilities and divide the work. Designated roles help teams approach the challenge from different perspectives: one person may focus on the user, another on business value, while someone else challenges assumptions and asks what could go wrong.

A key exercise is formulating ‘How Might We’ questions. This format helps teams make assumptions visible and turn a broad challenge into an actionable question:

‘How might we [achieve a goal] so that [a stakeholder] can [address a need or insight]?’

A useful question should be open enough to allow several solutions but focused enough to provide a clear starting point. Each team develops several questions before choosing which directions to explore during the sprint.

Learning by building

At PD6, prototypes are not polished miniatures of a final product. They are thinking tools: quick, tangible ways to explore an idea, communicate it to others and discover what does not work.

Teams use materials and methods that suit their challenge. A prototype might be a cardboard model, paper interface, scale model, staged service situation or simulated interaction. The emphasis is on speed and learning rather than finish.

Low-fidelity prototyping methods include:

• Cardboard prototypes for exploring the dimensions, features and intuitive use of a physical product.
• Paper prototypes for visualising and testing the basic flow of a digital service.
• Desktop walkthroughs for bringing a service environment and user scenario to life.
• Service staging for acting out how a service might work in practice.
• “Wizard of Oz” prototypes, in which a person secretly controls a complex function to simulate the user experience.

The central instruction is simple: build to think. Making an idea visible allows teams to discuss it concretely and invite others to react. Testing then reveals new questions, insights and opportunities for improvement.

A schedule built for momentum

PD6 follows a tightly structured schedule that balances planning, research, making and testing.

At the start of the day, teams create their master plan, assign roles, share their “How Might We” questions, prioritise needs and begin ideating. By the first checkpoint, the plan should be ready.

The middle of the day is reserved for contacting stakeholders, meeting external parties and building the first prototype. Teams are expected to make at least three phone calls to stakeholders, talk to someone from DF Labs, meet with at least one external party and document their testing.

The schedule leaves little room for discussion without action. Teams must move continuously between asking, making and testing.

Real conversations, quick experiments

Contact with people outside the team is an essential part of PD6. Teams are encouraged to reach out to stakeholders and external parties rather than rely solely on their own assumptions.

These conversations can challenge the initial interpretation of the brief. They may reveal that a perceived problem is not important to users, point to an overlooked need or suggest a completely different direction. Testing the prototype adds another layer of learning by showing how people respond to the idea in practice.

The requirement to document and present the testing also reinforces a central principle of the sprint: teams should be able to explain not only what they created, but what they learned.

A demo instead of slides

At the end of the day, each team presents its concept in a short, tightly timed presentation based on a tangible or visual demonstration rather than a slide deck.

The presentation begins with a brief description of the challenge. The team then demonstrates its prototype, explains the idea and presents the facts and insights that shaped it. Each presentation lasts a maximum of five minutes, followed by questions.

A mock-up, 3D model, paper interface or acted-out service can communicate the value of a concept more directly than a description alone. It also makes the development process visible. The prototype may be rough, incomplete or deliberately improvised, but it gives the audience something to respond to and helps the team explain what it has discovered.

Making room for uncertainty

PD6 rewards movement rather than certainty. Teams are expected to work quickly, generate many ideas and go beyond the most obvious solutions. A failed experiment is not wasted time if it leads to a clearer understanding of the challenge.

The day does not attempt to remove uncertainty from product development. Instead, it gives students a structured way to work with it: identify assumptions, speak with stakeholders, build something tangible and learn from the response.

“Starting top work in a project in a completely new context can be daunting. PD6 helps to make sure we don't just discuss PdP projects but fluently combine research, ideation and testing to learn our way forward in the diverse collaborations taking place in the course every year," Tua Björklund sums up.

By the end of the six hours, teams have not solved their sponsoring organisation’s challenge. They have something more useful for the next stage: a shared starting point, an initial prototype and new insights to carry into the actual PdP-project.