For most my career, I’ve worked at tech enabled organizations. Think large enterprises industries like financial services, insurance, and retail.

In the earlier part of my career, I filled business analyst or project manager roles in these organizations, often providing a bridge of sorts between “the business” and IT.

Based on the structure of the IT organization, I often had to do quite a bit of coordination to make sure the different IT teams focused on different parts of the tech stack worked together to build a solution.

When agile came about, the title changed to product owner, scrum master, or delivery lead, but the need for coordination was still usually there because the teams were not completely cross functional.

On top of that, every project I worked on was defined in terms of a solution to deliver.

My focus was on delivery.

The closest thing to discovery I experienced was the “requirements gathering” I did to understand the solution the team was told to build.

My experience is not unique

Since I’ve experienced the same thing at several companies in several industries, I’m comfortable saying my experience is not unusual.

So I can understand when people with similar backgrounds struggle to figure out how to balance discovery and delivery.

Most people moving into a product role in a tech enabled enterprise come from a business analysis or project management role where their focus was on delivery and they rarely performed true discovery.

What’s more, many of the developers that work in these organizations are used to business analysts and\or project managers providing requirements and coordinating efforts.

So when I started getting into situations where I could do discovery, I had to figure out ways to spend less time on delivery without it adversely affecting the end solution.

The resources I shared this week cover some thoughts on things you can do to become more effective with your involvement in delivery so that you can spend more time doing discovery activities.

It’s not about neglecting delivery altogether, it’s about finding the proper balance.

Discount to INDUSTRY Conferences

My friends at Product Collective regularly put on the premier conferences for software product managers. Even better, they put on three in person and one virtual conference each year so you have your choice of where to go.

The conferences coming up are:

New York Product Conference April 18, 2024 New York City, New York USA

Industry Europe June 17 - 19, 2024 Dublin, Ireland

Industry Global September 23 - 25, 2024 Cleveland, Ohio USA

Industry Virtual October 17 Anywhere

Registration is open for all four conferences. Go here for more information.

Plus, if you use the code INSIDEPRODUCT50 when you check out, you get an additional $50 off your registration. (Full disclosure - this is an affiliate offer)

And something else to consider - I’ll be at the New York Product Conference and Industry Global this year. I’d love to see you there.

​Register Today!​

Why product managers shouldn’t spoon feed developers priorities

A lot of PMs think their job is to manage everything that developers do. That’s not true. Product managers fill a portion of the development pipeline, while other teams–such as Quality Assurance (QA) and Development Operations (DevOps)–are responsible for other portions. Janna Bastow goes through what kind of tasks fill the development pipeline, who’s in charge of them, the proper allocation of the dev pipeline, and how PMs can help define these workflows and focus on their own objectives.

Product Managers Aren't Responsible for the Delivery of their Products

Product managers aren't responsible for the delivery of their products.

There has been a lot of talk recently about the role of product managers in companies, and the value that they bring to the table.

Jason Knight describes what product managers are not responsible for, because it’s something he’s seen often on his travels, and he thinks it’s at the root of much of the bad feeling between product managers and their teammates.

To cut a long story short, product managers are not responsible for the delivery of the products they manage.

A product manager’s guide to working with engineers

As Debbie Widjaja matured in her understanding of product management, she realized that trying to keep all engineers happy is a sure way to be a miserable PM. A product manager should be a multiplier of the engineers on a product team. To quote Liz Wiseman: Multipliers are the leaders who use their intelligence to amplify the smarts and capabilities of the surrounding people. Debbie created an acronym - ARISE - to describe how she works with engineers.

An example of backlog refinement for an internal product

Inspired by a trip to Fan Fest and touring Zac Brown’s Southern Ground recording studio (long story) it occurred to me that recording music can be very similar to developing software products. The people who truly have a passion for both pursuits don’t get hung up on process, but use process to help get them to great outcomes, whether that be an artistically pure recording or a product that solves customer’s problems.

As a result of that realization, I shared how the team I was working with at the time performed backlog refinement. When I wrote this, it was a work in progress, which I think is perhaps one of the more important points.

The approach I described in this article changed as we progressed through the effort as experience helped us refine our approach.

What is a delivery lead?

There’s a wide variety of roles that product people play in their organization. Along with common roles such as product management and business analysis, a new role that is starting to become more prevalent is delivery lead.

Because the role is fairly new, I thought it would be helpful to examine the role, identify its key responsibilities and explore different perspectives on the role.

Thanks for reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.

Talk to you next time,

Kent J. McDonald
Founder | KBP.Media