The initial excitement of an idea or being tasked with building a product can act like a starting gun where team members start running but without much awareness of where they are or where they are going.

I use a 2x2 ( (I believe I first saw this from Made By Many but its been years so i can't be sure) to help me place a team into one of the quadrants.

The 2x2 consists of an axis for problem and an axis for solution. The quadrants are then assigned a binary state of known and unknown.

Known Solution/Unknown Problem - Teams with a technologists bias will be in this quadrant. This could include Research and Development teams, large engineering organizations or even design teams that get energized by clever solutions. These teams create novel technical solutions to unknown problems.

They will produce amazing demos and Proof of Experience (POE) but they aren't coherent products. They will build thing that impress other technologists or designers but don't have a lot of conviction on what benefit it has for people. The team has, most likely, imagined a problem for imaginary people. Or solved a self serving problem that is only of interest to peers of very like minded people.

"Incubators" "labs" "innovation teams" tend to sit in this quadrant. They can generate a lot of cool things but have a low success rate turning them into viable products. They focus on solutions first. While some of these ideas will find a problem to solve, most are just interesting experiments.

Unknown Problem/Unknown Solution - this is the most ambiguous of spaces. If a team neither understands the problem it is trying to solve or potential technical solutions it is likely adrift. Teams are in this quadrant for two reasons

1. Looking new markets or opportunities - they have been asked, by leaders, to find a new market opportunity outside the existing business. These teams are given broad asks like "What could we do in streaming?", "what is our next high growth business?"

2. The team is lost - a team has lost its way. It is casting about for purpose. Most commonly this will show up as the team not rowing together. There is no consistent answer on what they are building and for who they are building it.

Regardless of the reason, you want to get teams out of this zone. If they have been given a mandate to find new market opportunities they need a solid playbook. IME most companies do not have battle tested methods to do this. Instead they try to produce a high volume of solutions and hope that one finds a market. While this "spray and pray" approach is a thing, companies need to be willing to accept the low success rate inherent in this method. It requires a stomach for failure and some way to assess progress.

If it is situation 2, the team needs to find a problem to solve ASAP or leadership needs to dissolve the team.

Known Problem/Unknown Solution - Having a well articulated problem to solve is the most consistent path to designing and building good products, i've found. If the team is laser focussed and aligned on a well articulated problem then they can create potential solutions to that problem. With potential solutions in hand they can go through whatever validation process to find candidates for shipping.

Some traps people fall into here

1. Internal Problems - Too many teams solve problems, who's primary value is internal to the company. It is not something people outside the enterprise have, it is a problem the people inside the enterprise have. This can be anything from an imagined problem (see above) that is really just a problem a small group of technologists have to a problem that only benefits the company.
   When I reference a "problem", I mean that it is is a real problem that real people have. This problem has been found by talking to people (Research) or has emerged through usage of a product (Data Science). Regardless the problem is grounded in reality, not imagined.

2. Trying to solve too many problems - even when teams find real problems they will try to solve all of them at once. This is a form of risk mitigation. By trying to solve multiple problems it allows a team to not have conviction. They believe they can test their way to conviction. This doesn't work.

Known Problem/Known Solution - This is when a team is being asked to do something they've done multiple times before. They understand the problems and the solution. This is work where well established patterns exist and little value in reinventing the wheel.

Teams will resist being in this space. They want to be novel and get the recognition of building something new. They will try to argue that their problem or solution is novel. It isn't.

In most cases, I want teams to be moving from known problem and then work through solutions until they find the right problem/solution space. For pure research and development, companies need a defined process for technology transfer. A method for moving solutions out of the lab and into products.