Forming Fast Product Problem-solving Iterations

Scope of the Article

In this article, I am focusing on the decision-making process of an efficient product problem-solving cycle. Of course, a product management team with high-quality talent is a prerequisite, and I will cover it in another article. Focus and clear alignment of priorities for the product team with the company's priorities are also important, as TuSimple is still a research company and we do not have customer demands as our prioritization principle. The RICE model generally does not work well here.

Note: One can argue that the product team can identify internal users as customers and conduct prioritization. Please refer to my other article for my thoughts.

Definition

1. High efficiency is achieved under the prerequisite of delivering high-quality products.

2. High-quality products are identified by achieving pre-identified goals.

3. The goals should be either binary or quantitative: 3.1 Solving an existing or future pain point or not. 3.2 Improving a data metric or not.

In this article, within TuSimple's context, I define efficiency as the time from a pain point emerging to the time that the acceptance criteria have been met or the theoretical problem-solving prerequisites have been met. For example, if we find the disengagement rate increased during the past 30 days, the definition of done for the efficiency criteria cycle should be the release of the new algorithm changes that theoretically solve the false disengagement issue.

Modeling

The essence of the problem-solving model: Building a model is essentially building a workflow for decision-making. A typical problem-solving cycle in TuSimple is to:

1. Identify priorities: Determine which problems to focus on.

2. Identify problems and solutions: Understand the root cause and how to solve it.

3. Communicate and execute the solution and verify the resolution of the problems: Execute and verify the solution.

I consider stakeholders in the problem-solving process as forming a 'thinking group' (not groupthink, lol) and believe that a highly efficient problem-solving cycle can be transferred and consists of three parts:

• Pre-decision: The phase where all stakeholders reach the same context and mental readiness about the problem and form their individual solutions for the problem.

• Decision-making: The phase where solutions are communicated, and agreements are reached on directions.

• Post-decision: The phase where the solution, in terms of execution, is formalized and executed.

Difficulties

The achievement of maximized efficiencies in this model depends on:

• The standardized understanding of the problem scope

• The maximized involvement in the decision-making process - meaning max out the total intelligence of the thinking group

• The reach of agreements among stakeholders - disagreements can caused by different aspects/understanding of the problem scope

Also, the lack of a passive feedback loop and/or failures in the installation of the decision-making process during the post-decision execution phase can lead to:

• Excessive small changes to the product (Ship of Theseus)

• The underachievement of the product goals (we didn't achieve this because of XYZ, and it's not my fault)

• Failures in achieving the expected outcome

Solutions and Implementations

They are not prioritized but rather based on the order of the three steps that I mentioned before:

Keep Contexts Handy

Here, by context, I refer to product items and action items.

Context about the Product

• User research docs, PRDs, designs, and data collection docs

• PRDs and design should be up-to-date and match online product logics

• Materials should be on Confluence instead of scattered on Google Drive to ensure accessibility

• Problem descriptions

• Jira tickets or descriptions from Pagers should be shared and made public

Context about the Role

• Keep a list of stakeholders so that we can also know who to reach out to. Especially for products such as HMI

Maximize Participation in Thinking

• Avoid being dependent thinkers

  • Build your own source of truth: Gather product managers' own understanding of problems, especially those two-sided problems with public interactions or non-tech users

  • Ingest context provided by researchers and developers: Dig into the reasoning, instead of only conclusions

• Encourage solution-oriented thinking

  • Focus on the improvement of the system. High-dependent systems design, such as AV development, often triggers users to find problems from operations instead of the systems, as human operators are easier to make mistakes. Yet solving people's problems has a much lower priority

• Be nice to people, but not to people's ideas

  • Expect and lead debates and challenges. Don't be frightened by challenges, and don't be afraid of coming up with challenges for others. It's common to 'care for others' feelings,' but that is essentially self-protection

Run the Experiments and Get the Data

• Identify the hypothesis

  • Refer to the research guideline

• Don't forget the simulation ecosystem

  • Creating logic and scenarios in the sim system can be boring but is essential for the baseline to be created

• Do not expect a perfect solution from the beginning

  • Instead, use a spiral or progressive design method to get quick wins and solve the problem systematically when you can achieve both simultaneously

Manage Expectations

• Manage your time

• Manage the expected outcome of a meeting or a testing

• Manage the expected product delivery for users