The problem model

One of the pitfalls' product teams and companies often takes is to think in features & innovation however once the feature is launched is barely used and ends up add more complexity to your product and more resource overhead for QA, Engineering and designer for maintaining the feature. The problem model is here to help with that.

The problem process

Your roadmap for your product should be problem based, not feature based. Moving from designing things right to designing the right thing is critical for any products' success.

When your product roadmap consists of features, you're already framing the solution, this might flood into decision-making when doing research and decision meetings.

By stepping away from feature and looking at problems, you have a project brief that is living, that requires answers.

It starts with a problem

When using this model, it's critical that you start with the problem, together with the problem you build hypotheses that can help you set the right research methods and bring more clarity to what needs to be researched. If your team is already using a research repository, then the problems will most likely feeding into this step.

Research

Once one or more problems and hypotheses have been established, you move into research. Most product problems requires the user's voice, so depending on your setup you might already have users reachable, otherwise now is the time to set up automated recruiting for such.

Outcome

This step is unfortunately something most product and design teams don't spend enough time on, it's crucial for any business to know why certain resources are spent, building new offerings often require a whole set of departments from UX research, Product managers, Engineers, QA's and even internal educations for teams like support, sales and marketing. To make sure these resources are well spent, we need to define clear outcomes we expect this problem solution can help with, outcomes that can be measured either through surveys, user behaviour or new sales.

Building

In the building stage, you or your team uses different tools and techniques to scaffold and prototype different solutions to reach the define outcome, the important step here is to quickly evaluate different paths and narrowing it down to 1–3 designs. It's very important that the building phase only focuses on the Problem, Research and Outcome as any new ideas coming up through this phase should be put for release cycle, the goal for building is to fix the problem your user/product/service have.

Launch

This phase should be known for most product and design teams, however at this stage it's important to have a launch strategy, do we have the setup to measure the outcome, do we have the documentation and guidance for our users.

Evaluate

Now your new solution have been running for a few days or weeks depending on your user base, and you will evaluate if you reached the desired define outcome from earlier in the process, furthermore you will most likely have learned quite some new stuff about your users, their behaviours and their problems this need to be evaluated.

Manifest

After you evaluated the new solutions, you need to make sure the project learnings are manifested throughout the team, this can be done with research repository, a one-stop hub for all your research, outcomes and evaluations. Your team might have learned something critical throughout this project that serve great value for the sales, support or other product teams, this needs to be shared.