It’s Time to Improve Your Product Engineering Conversation

“Truly great delivered product is the result of a team, a true partnership between product and engineering.” [1]

---

As a product guy, I’ve worked with hundreds of software engineers and counting. Those Devs have been some of my favorite people throughout my career. “Software is eating the world.”[2] Devs everywhere should be proud of what they’ve built.

But just as those past successes were not automatic, neither will be future successes. We need to keep improving. And it’s in that spirit that I have a couple suggestions for my Dev friends who write code. Here’s why.

Get the best outcomes. Period.

Getting the best outcomes is ultimately why I have suggestions for my Dev friends. Getting the best outcomes possible is ultimately why this matters.

I’ll make suggestions in the form of a couple hypothetical conversations. I’ll show what “bad” looks like. And I’ll suggest what “good” could look like, so we can compare and contrast the good and bad outcomes. I’ll also poke a little fun at both of us in the example conversations to keep it light.

Our hypothetical scenario

Suppose we work for an app development startup. Our mobile app helps vinyl record collectors keep track of what’s on their shelves and expand their collections with music they’re likely to enjoy.

We’ve got a product our customers love, our “machines” are learning what music our customers like, and we’re starting to make money. Sounds pretty perfect, right?

But there’s always room to improve.

Around here, we eat our own cooking

Imagine that I’m using our app with my own record collection. I notice a key visual isn’t updating correctly. Our visualization of musical genres has the categories mixed up.

Looks like something broke.

I let you know about the issue. Our ensuing conversation goes something like the one below.

Example Conversation 1: What “bad” looks like

Me: “Hey, I’m using the app update we want to ship next week. I just added a couple records to my collection and noticed the data visualization is wrong.”

Dev: “That’s strange. We didn’t touch that in this sprint.”

Me: “Oh okay. So nothing changed?”

Dev: “Oh wait, maybe we did touch that. I think I know what’s wrong. Let me try a few things.”

Two hours later…

Dev: “Can you retest my fix and tell me if it works? I’m still not really sure what’s causing this.”

Me: “Sure…I’ll take another look. Right after my 3:00pm meeting.”

Two days later… 😉

Me: “Still not working for me.”

Dev: “Okay try again now. I was missing something.”

Me: “Still not working.”

You get the idea. Swirl.

Clearly our conversation needs to change.

The bad outcomes

A lack of inquisitive action in the example above results in bad outcomes that have long-term effects:

1. The root cause of the issue is not known. You’re flying blind.
2. The attempted fixes may have just suppressed the known symptoms, but not yet other unknown symptoms.
3. It’s likely the attempted fixes will have other unintended consequences that will cause problems in the future. It’s rare that unnecessary code clutter remains neutral.
4. Nothing new was learned as input for continuous improvement.

A trial-and-error approach makes sense some of the time. In this case though, we see what the bad outcomes are from not enough inquisitive action.

Here’s what happens when you get inquisitive and take action

Our conversation needs to change. We will get better outcomes as a result.

Example Conversation 2: What “good” looks like

Me: “Hey, thanks for bugging me to use the beta app in TestFlight. I just added a couple records to my collection and noticed the data visualization is now wrong.”

Dev: “Okay. Show me. Let’s try to reproduce the issue on my device.”

Me: “Okay sure.”

Dev: “Yep, I see what you mean. That’s not right. I’ll look into it. I may need to ask around, and may need your help prioritizing my other work. I’ll let you know.”

Me: “Okay sounds good. Thanks.”

Two hours later…

Dev: “We found the root cause. Tomorrow we’ll have a couple options we can review with you. There may need to be some trade offs to get this fixed.”

Me: “Sure thing. Talk to you tomorrow. Thanks.”

During the next sprint, after choosing a fix option…

Dev: “Okay. I retested the fix we all agreed to. It’s working for me; it’s ready for you to retest now too.”

Me: “Yep, it’s working for me now too. Nice work, thanks.”

Dev: “Great. I’ll let the team know what we learned. We’ll review at our sprint retrospective, too, and see if any improvements make sense.”

Success. That’s what “good” looks like.

If only it were always that simple and straightforward!

The good outcomes

Here are the good outcomes we gain as a result of the inquisitive action in the second example:

1. The root cause of the issue is known. The world is your oyster.
2. The fix was verified to address the issue, not just suppress the symptoms.
3. The fix was surgical, isolated, and did not introduce unintended consequences.
4. We learned a few things that will improve the results of future development and quality.

In this example of what “good” looks like, you showed you own the code. You took personal responsibility for the outcomes, and that’s always the right approach. You acted like an owner. You delivered more than a mercenary’s outcomes.

TEST THE OUTCOMES

Don’t just take my word for it. Test the outcomes.

The best outcomes are measurable because they help drive business and customer success. In fact, if your outcomes don’t drive these successes, you probably aren’t focused on the right results. Test your outcomes against this measurement standard. Bug your product team to keep you informed of the results.

“If it’s not about increasing the revenue, achieving high customer satisfaction and growing the business, then why track it?” [3]

A note about your impact within a large organization

If you’re in a large organization, measuring specific outcomes may seem daunting and difficult.

It’s true that smaller startups are often in a different situation. Even minor changes and results are more likely measurable. In these situations, you have the ability to control the variables and attribute results to a source. However, all organizations should aspire to measure their best outcomes.

Be creative and find a way.

Get inquisitive and take action

It’s not hard to improve your product engineering conversation. Start by getting inquisitive and taking action. You’ll get the best outcomes possible. And getting the best outcomes is why this matters.

---

Also shared on Medium.