Learn

👨‍🏫 Problems First, Solutions Second

Problems are more important than solutions. Don’t believe me? Let’s dive in.

• Have you ever seen a program veering off course because the problem wasn’t fully understood from the start? 

• What about when a feature is launched, only to realize it barely resonates with users?

• How about those times when it feels nearly impossible to get traction with an awesome solution because it didn’t have a compelling story behind it?

Misaligned problem statements can cascade into costly missteps, wasted time, and frustrated teams.

As a Technical Program Manager, one of your core roles is to drive clarity and alignment. This all starts with the problem.

Without aligned specificity of the problem to be solved, solution design and execution will likely fail.

A Bloated Problem Lead To Bottlenecks

About a year ago, I was dropped into a struggling program. Lucky me!

The expectation was for me to drive clarity and alignment between engineering and product so that we didn’t miss the customer-committed deadline which was fast approaching.

Technical Program Management Perspective: Lack of Clarity and Alignment

Jumping into the middle of all this, I didn’t initially have the context for both engineering and product. This was a process of discovery to get clarity so we could then drive alignment.

I knew is that we needed to find a way to negotiate either timeline or scope. But I wasn’t sure how to figure this out at first. The more time I spent with each group (both separately and together), the core alignment issue became clear:

The problem had become excessively bloated, leading to requirements also being bloated.

Engineering’s Perspective: Defending Time and Resources

The engineering teams were overloaded with a million other things. Upon hearing the request from product management to enhance the feature set for a portion of our core platform, they immediately became defensive of their time (appropriately so! Any good Engineering Manager defends their team ferociously!).

They could see what was being asked for and immediately knew it would consume more time than they could give.

Yes, it would a good long-term uplift to one of our core systems, but within the communicated timeline? Laughable.

Product’s Perspective: Building Customer Value

The product team saw an opportunity. Through conversations with customers, they realized that there was direct revenue potential if they could deliver an enhanced feature set on this portion of the core platform.

Product set the requirements to truly delight the customer, as any good product management team would do. These definitely qualified as “wow-factor” requirements. Then they began negotiations with engineering.

Bringing All Perspectives Together.

Okay like I said, I was dropped into this middle of all these negotiations. Emotions were high. The meetings were tense. But both groups wanted a solution.

With product management, I began to trace the original problem back to its origin. This “tracing back to the problem” exercise took the form of these questions:

• Why are we doing this?

• What pain point are we solving?

• Who asked for it?

• What does this do for the business?

• What is at risk if we don’t do it?

After diving into this with the product team and doing additional research with them, we discovered 1 very important fact that was lost in the details.

The original request was from 1 customer for a very narrow set of requirements by a very specific date.

This was a game changer.

We compared the list of requirements that product had written with the actual problems the customer wanted solved. Wow. The list of features being requested from engineering shrank quickly.

So what happened?

You may think that product did a terrible job here. Or maybe you think engineering was too inflexible.

The truth is that thinking that was isn’t helpful to anyone.

Here’s what is helpful:

• Product excelled at future-proofing and considering value beyond one customer, though initial alignment with engineering was missing.

• Engineering communicated capacity constraints effectively, preventing overpromising and ensuring realistic timelines once clarity was established

The core issue is that the the problem definition for the first iteration wasn’t clear nor aligned.

As a TPM, I helped the group resolve this. But I had a very useful framework in my back pocket that helped me coach these teams towards a better collaborative model.

The Double Diamond Framework

The Double Diamond framework isn’t just another process model. For me, it was a roadmap to steer these teams toward clear problem definitions and aligned solutions, minimizing wasted efforts and maximizing impact.

Let’s be honest, there are a million problems that could be solved.

How did I use this framework in my scenario described above?

I used this framework by bringing us back to the basics of problem discovery and definition.

With Product, we collected all the problems they were hoping to address with their current requirement list (problem divergence in the framework). Then we started to narrow down the list relative to validated customer needs (problem convergence in the framework).

There is no one-size fits all on how to use this framework. After all, this is a product framework. But it serves as an excellent model to facilitate effective collaboration.

Here are 3 ways you and I as TPM’s can use this framework:

• Enhancing Communication in Discover - We can lead early discovery sessions in partnership with Product Management, aligning stakeholders on the core problem through workshops and structured discussions.

• Defining Clear Metrics in Define - We can ensure success metrics mirror the problem’s scope, using dashboards to track progress and keep teams focused.

• Ensure Focused Execution in Develop - We can work across engineering teams to drive clarity of solution design and prevent scope creep, which helps us stay laser focused on the expected outcomes.

• Seamless Handoffs in Deliver - We can coordinate handoff processes with documentation, training, and support, ensuring long-term sustainability post-launch.

By adding this framework to your TPM tool-belt, you become a much stronger leader and collaborator across engineering and product organizations. Large-scale initiatives need quality leadership, and when we as TPM’s leverage the Double Diamond framework, we bring clarity and alignment from the start.

Happy TPM-ing!

A word from this week’s sponsor…

Add file uploads instantly with Pinata’s developer-friendly File API

As a developer, your time is valuable. That’s why Pinata’s File API is built to simplify file management, letting you add uploads and retrieval quickly and effortlessly. Forget the headache of complex setups—our API integrates in minutes, so you can spend more time coding and less time on configurations. With secure, scalable storage and easy-to-use endpoints, Pinata takes the stress out of file handling, giving you a streamlined experience to focus on what really matters: building your app.

Start building!

Events

🎉 TPM Events

Do you want to meet other Technical Program Managers in-person?

Don’t forget about the local chapters called TPM Trails. These are city-specific TPM meet ups! I unfortunately don’t have any near me at this time, but I certainly hope others can take advantage of it.

This page is regularly updated with upcoming events, bookmark it!