PDW’s are so important that we created a compressed version for the busy bees

To all the busy CXOs and teams, here is a version of the PDW that is compressed but with the full impact.

We have written an extensive article on PDW - Product discovery Workshop, which is like our go-to guide for all new projects Skcript works on. Why do we need PDW? Why not jump into a tech discussion or development directly?

• Miscalculation of the timeline and value
• Missing out on the requirements
• Under/Over validation of the idea
• Not choosing the best tools for the development of the ideaÂ
• Bringing in the right people and selecting the right resources for working on the idea.

Technology decision and choices are best made after identifying and understanding the requirements well as enabled by the PDW. We have compressed the three-day workshop for all the busy CXOs and teams, to imply the importance of PDW and keeping in mind the time constraints of the stakeholders. The steps are as listed below.

Pre-workshop steps:

Step 1:

Discuss the one-line description of the project. The idea head or the product person will explain the one-line description of the product.

Step 2:

Gather all documents, materials that can explain the requirements and idea better. As a preparation before the PDW, the execution team representatives should be well educated on the context, a high-level overview of the product and its features.

Step 3:

Check the availability of the team and plan for an on-call PDW. Things to remember while planning the compressed PDW.

• The right group of participants
• Asking the right questions
• Being prepared to pivot from the plan
• Capturing the unexpected

The master takes up the responsibility of gathering the right team, plan for the meeting based on the availability. A well allocated 60-90 mins are suggested.

PDW:

Step 4:

Time to be consumed: 30 - 40 mins.

I am categorizing the method into two; a workshop for building a new idea and workshop for revamping/iterating an existing product/project.

4.1:

Workshop for revamping/iterating an existing product/project - Agenda

• Identify the end goals
• What is the new feature the stakeholders are trying to achieve?
• How would the stakeholders like the new version to be perceived?
• Reason for revamp?
• Improvements that are expected to be achieved.
• Inspirations that stakeholders want.
• Cleaning the existing feature set by deciding what goes on and what gets left behind.

4.2:

Workshop for building a new idea:

• The end goal stakeholders are trying to achieve.
• Problem statement and the solution we are aiming to provide.
• USP of the product
• Competitors in the market and existing inspirations.
• The complexity of the features and the critical feature to be highlighted
• Roadmap and future scope as perceived by the Stakeholders, to plan the expansion of the product.
• List the features that will be built.

The weight of getting the stakeholders and the team to answer the above is on the master. The others should be actively evaluating the suggested points.

More information is appreciated but deviating from the goal is highly possible, and hence, the team should steer clear of distractions.

Step 5:

Time to be consumed: 10 - 20 mins

Discuss the possible tech stack that can be used in the development. This idea to be pitched by the development team lead and the tech lead from the stakeholder side will give their comments on the same.

Choosing the tech stack is crucial as they are the foundation and the building blocks of the product.

Step 6:

Involving both the teams is crucial. Takedown notes, as much as possible. Both the sides should take notes and share it to ensure that all points were captured.

Step 7:

Time consumed: 10 - 15 mins

Going through the agreed points and the requirements in brief. In other words, a sum-up of the PDW session that happened to ensure everyone is one the same page and prioritize. From the gathered information, both the teams can prioritize and the rank the points to indicate the importance. Â

Post-PDW:

Step 8:

Intimating the team about the next actionable, which will be:

• The development side team to come up with a document that captures the problem statement, the solution to be provided, requirement set, inspirations as listed, tech stack to be used, and project estimation.
• The project estimation will comprise of the development timeline, effort days and hours, and people involved.

Stakeholders will have to confirm on the documents or make iteration by providing comments.

Points to remember:

• Decision-maker decision is final. There is no going back.
• Set the agenda ahead and try to cover the crucial points.
• Preparation is required by both teams, and letting each other know about the study to be done will help in saving time.
• Email communications pre-workshop are encouraged.

Up next