Product thinking strategy questionnaire

11 May 2022 | Product Management

Aqui você irá aprender sobre:

Aquí aprenderás sobre:

Here you will learn about:

Ici, vous apprendrez:

Qui imparerai a conoscere:

Hier erfahren Sie Folgendes:

The questionnaire below elaborates on a few important aspects of product thinking, problem understanding, solutioning and strategic delivery planning.

 

I have used this questionnaire as part of a workshop on Product Leadership and Strategic Alignment. Basically, the group go over a few initiatives/projects and answer the following questions (for important Product Thinking topics).

 

[Upfront analysis] How much upfront analysis do you do?

  1. A lot. I will perform several interviews and requirement gathering, in a few months.
  2. I will perform a good number of interviews and user research in a few weeks.
  3. I will perform some interviews and user research in a week.
  4. I will go straight into solutioning.

 

[User interviews] How many users / stakeholders would you interview?

  1. A lot. I want to get a detailed view and understanding from as many people as possible involved in this problem space.
  2. I want to get a big picture understanding from many people involved in this problem space.
  3. I want to interview a few key people to get a good understanding from the problem context.
  4. Instead of interviewing I will show them something real and learn from their reaction using / trying to use it.

 

[Solution for the problem] How much of a solutioning do you plan before getting started on building it?

  1. A lot. I will have a very detailed plan for the solution. Everyone will be able to follow the project progress, as per the plan.
  2. I will try to solve a substantial part of the problem on the first release. Although, I will plan a few releases, delivering the full solution incrementally. I will start on release 1, then release 2, then release 3 and so forth.
  3. I will try to solve a very minimum part of the problem. But I will use this minimum part to get me close to the users so I can validate the direction of the solution for the next increments.
  4. I will not try to solve the problem, instead I will only try to learn. I will build something to provide me learning from the users.

 

[Prototyping and sketching] How much prototyping and user experience sketching do you do?

  1. A lot. I will create high-fidelity user experience for the User Interface of my solution. I will impress my stakeholders! Later I will plan how to build it.
  2. I will create prototyping and a user experience for the most important user scenarios of my solution. I want to show it to my stakeholders so they can visualize it. Later I will plan how to build it.
  3. I will not create prototyping and a user experience for the whole solution. But I will prototype the user experience for the Minimum Viable Product (MVP). The MVP will help us validate the hypotheses and business direction for our solution.
  4. None, or almost none. I will, at most, have a few drawings in a napkin for some very minimum thing I will build, really fast, and make available to a few early adopters or beta users. I want to move super-fast to learn from these early adopters.

 

[Delivery planning] How much will you plan your product delivery?

  1. All of it. I will share a plan for the all the planned releases and their backlog of work including User Stories, technical tasks, and User Interface.
  2. A good amount. I will share a detailed plan for the first release with all the backlog of work including User Stories, technical tasks, and User Interface. I will not share a detailed plan for release two, release three and beyond. If needed, for these releases, I will share a high-level plan with epics and features.
  3. A little. I will share a plan for the Minimum Viable Product (MVP). But it is not a detailed plan with all the backlog of work including User Stories, technical tasks, and User Interface. The plan shows a minimum set of features to be worked on, with the goal of validating the business hypotheses. Once the MVP plan is accepted by stakeholders, the delivery team will define, prioritize, and refine the User Stories for the MVP.
  4. I will start with an experiment. I will show it to a few people. Later I will decide how to evolve it. I need freedom to innovate.

 

[User feedback] How often will you seek user (real usage) feedback?

  1. Very little. It will take me a long time to work on the full solution. Then, after quite a few months, I will release it. So, it will take a while until I am able to receive user feedback.
  2. In larger periods. As I will be releasing some often (release 1, release 2, etc.), I will seek user feedback after each release. Perhaps, if the feedback impacts future features or the direction of the solution, I will adjust the planned releases.
  3. As I am working with MVP and product increments, I need to be constantly validating the user feedback to make important decisions.
  4. More than continuously. Even before having a real product, I was already experimenting with the early adopters. I consider feedback essential for business direction validation. But I also use it as an engine for innovation. I am always learning form the users. Such learning helps me elaborate good and innovative business hypothesis.

 

 

This questionnaire was useful for me to get a feeling about the group appetite for working with Minimum Viable Product, Product Thinking and Lean Inception (the continuation of the workshop).

When running the workshop for an organisation, I will track the answers on the Product Thinking Questionnaire Shared Google Excel. It generates a simple spider chart graph. With it you can see the whole picture for how the organisation currently handles these important aspects of Product Thinking.  It does show the appetite for innovation and experimentation. It can also show some discrepancies. For example: a lot of upfront analysis, but the desire to have a minimum plan for the MVP. it is also useful to repeat the same questionnaire to the same group of people after a few months and compare the charts.

Download this post by entering your email below

Do not worry, we do not spam.

 

 

Paulo Caroli

Paulo Caroli is the author of the best-selling book “Lean Inception: How to Align People and Build the Right Product” (the first on a series of books about Lean Strategy and Delivery). He's also the creator of FunRetrospectives.com , a site and book about retrospectives, futurospectives and team building activities. Caroli writes on this blog frequently. Receive the next post in your email. Sign up here .
New Book Alert: How to Define, Prioritize and Refine User Stories using the Product Backlog Building Canvas

New Book Alert: How to Define, Prioritize and Refine User Stories using the Product Backlog Building Canvas

Introducing our enhanced book, “How to Define, Prioritize and Refine User Stories using the Product Backlog Building Canvas.” Evolving from its predecessor, this edition responds to valuable reader feedback, refining both content and title. Delve into the world of effective product development and user story management, discovering the integrated power of the PBB Canvas. Embrace an enriched reading experience and explore insights from thought leader Jeff Gothelf in the preface. Don’t miss a reader’s insightful review, preserved for wider readership. Join us on this journey of empowering user story craftsmanship, and witness the transformation of your product development goals.

read more
FunRetrospectives.com redesign

FunRetrospectives.com redesign

Amongst other things, I really like MVP and retrospectives. This probably explains FunRetrospectives.com over the years. FunRetrospectives.com is a simple dedicated blog for sharing proven retrospectives activities. The site gets lots of access. I believe it has to do...

read more

Pin It on Pinterest