“Truly great delivered product is the result of a team, a true partnership between product and engineering.” 
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.” 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.
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.
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.
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.
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.”
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.”
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.
A lack of inquisitive action in the example above results in bad outcomes that have long-term effects:
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.
Our conversation needs to change. We will get better outcomes as a result.
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.”
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.”
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!
Here are the good outcomes we gain as a result of the inquisitive action in the second example:
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.
We’ve changed our conversation. We’re working together more intentionally and smarter to get the best 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?” 
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.
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.