Have you ever heard a user telling you that I need a new "dashboard" or I need an "Analytics solution" a new "XYZ".
They start the conversation by describing a solution.
They saw another cloud product with a solution that seems to be a solving a big problem but instead of describing the problem, they jump to the solution.
In these situations, please try to move the conversation to the problem they are trying. Michael Porter used to call this methodology the "5 whys". Tell me more about your idea, why do you think you need this new dashboard? and then continue to dig into the issues the end user is trying to solve.
In order to make sure my product managers also fully understand what problems they are trying to solve, I tend to enforce a product design process in 3 milestones or Design Reviews.
The two primary objectives of this Product Design Process are
To approach product initiatives with increased rigor, encouraging us to work thoroughly and accurately.
To align work across Product, Engineering and Product Design using a shared framework.
The distinct stages and requirements of each are outlined below. As a team, we approach and discuss development through this framework. For example, we have a weekly Product Team meeting where we review the status of the product design according to the DR phase they are in.
Design Review 1: Problem Statement
Definition: Agree on what problem(s) we want to solve
Owner: Product Manager
Deliverable: Outline of agreed on problem statement(s) - be specific and succinct (e.g., if a writeup, should not exceed 1 page, most of the time, it is a simple paragraph)
Stakeholders: Speak to whoever you must to understand the problem you are trying to solve (ex: sales; CS; Community but also customers or prospects that did not select our platform)
Design Review 2: Solution Description
Definition: Proposed solution to the problem identified in DR1
Owner: Product Manager with Engineer lead
Deliverable: Documentation on proposed solution(s) per problem statement - be succinct and specific (e.g., a few slides slides if PPT or 1 written page per solution per problem if full text document.
Stakeholders: Product and Engineering partnership, begin engaging product design so they get familiar with the problem and solution.
I have seen some amazing DR2s where an Engineer comes with simple, elegant solution that is easy to implement. I love solutions that are simple and can be developed in one to 2 sprints.
But sometimes the solution is so complicated that it is obvious the problem is too hard to solve in one iteration so you need to go back to DR1 and find an easier problem to solve. Don't feel bad to give up on your big beautiful problem, cut the big problems into smaller ones and work in phases. A simple solution guarantees a rapid software delivery.
Design review 3: Prototyping
Definition: Feasibility study preceding implementation. Proof of concept (POC) phase lasting a few days to a few weeks to help understand the work that needs to be done
Owner: Product Manager working with Design lead and Engineering Lead
Deliverables:
Prototype/wireframe in Figma (Design). This is where the US designers do their user research as well, so please be patient. It takes time to create a great product.
Coding POCs to evaluate some new technologies identified during DR2. The goals are to answer 2 questions: a) does engineering know how to develop the solution and b) what is the level of effort needed to deliver the solution.
Planning schedule (Product Ops working with Engineering)
Stakeholders: Product, Engineering and Design
This seems pretty linear right? It is not Linear, far from it.
I like the outcome of a DR 3 to be something that we can deliver in 1 to 4 sprints max. Often we end up iterating between DR1 and DR2 and other times we exit DR3 with a planning that includes 2 or more phases. The main goal is here is to deliver fast, go GA and then start the next phase.
Another trick is to avoid trying to solve too many problems with the same solution. you might end up with a partial solution to too many problems or a solution too hard to develop in one iteration.
I also use a template to capture all my design reviews and ask the teams to keep every DRs to one page max. You can download it on this page.
Hey what’s up ?
Hii
Hello would you mind to talk to me