Product thinking strategy questionnaire
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. Basically, the group would go over a few initiatives/projects and answer these questions.
How much upfront analysis do you do?
- I will go straight into solutioning.
- I will perform some interviews and user research in a week.
- I will perform a good number of interviews and user research in a few weeks.
- A lot. I will perform several interviews and requirement gathering, in a few months.
How many users / stakeholders would you interview?
- Instead of interviewing I will show them something real and learn from their reaction using / trying to use it.
- I want to interview a few key people to get a good understanding from the problem context.
- I want to get a big picture understanding from many people involved in this problem space.
- A lot. I want to get a detailed view and understanding from as many people as possible involved in this problem space.
How much of a solutioning do you plan before getting started on building it?
- 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.
- 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.
- 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.
- 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.
How much prototyping and user experience sketching do you do?
- 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.
- 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.
- 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.
- 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.
How much will you plan your product delivery?
- 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.
- 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.
- 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.
- 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.
How often will you seek user (real usage) feedback?
- 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.
- 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.
- As I am working with MVP and product increments, I need to be constantly validating the user feedback to make important decisions.
- 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.