Observations from INDUSTRY The Product Conference
Thoughts from a product management conference through an internal product lens.
I spent most of last week in Cleveland, Ohio attending INDUSTRY The Product Conference. I was in charge of compiling the notes that the folks at Product Collective sends out to attendees the day after the conference, so I was a little busy.
I like compiling the notes because it forces me to pay very close attention to all the sessions during the conference, something I’m not inclined to do at other conferences.
When I compiled the notes, I tried to keep them as true to the content of the presentations as possible.
That said, there were certain points made throughout the conference that stuck with me more than others. I attribute that to listening through my internal product filter. I thought I’d share those key points.
Producing impact is more important that doing things “the right way”
Matt LeMay, Author of Product Management in Practice, started off the conference with a reminder that product teams need to produce impact for their organization, even if it means going against “the right way,” or my favorite phrase to hate, “best practices.”
There are product management “thought leaders” who like to espouse the “right way” to do things. When active product managers follow that advice blindly, they end up losing site of the commercial realities of the organization they work for.
Matt brought that issue home:
Even if you’re doing things “the right way”, if you’re not doing the work that helps your organization in measurable ways, you’re in a vulnerable position.
His prescription: make sure your day-to-day work - the things you do as a product team (Design and technology decisions, prioritization) - are aligned with impact - the measurable success of your business (Revenue, profitability, growth).
And if you work on software your organization builds for its own use, It’s important that your team regularly and proactively discuss how you are adding impact for your business.
What does this team need to achieve to be considered a successful part of the organization? If you were in charge of the organization, would you fully fund this team?
Organizations are getting more interested in Super IC’s
There were a couple of themes running through several of the presentations at INDUSTRY. One of the themes was how to be a better product leader.
Maggie Crowley, VP of Product at Toast, contributed to that theme from the angle of how product leaders can support more experienced Individual Contributors known as “Super ICs”.
Maggie observed that product management is catching up with engineering to have dual career paths, opening the opportunity for Super ICs.
At the same time, companies are taking a hard look at product teams and thinking about unit economics. They often prefer experienced Super IC’s over people managing a couple of people.
Organization structures are becoming flatter, with a heavier reliance on highly experienced individual contributors.
That all means if you’re want to advance your career (and your paycheck) you’re going to have opportunities to do that without having to manage people, and I think that’s a good thing.
A lot of people are talking about AI, here’s the important bit
The other recurring theme was, surprise surprise, Artificial Intelligence. This shouldn’t come as a surprise given how organizations seems to be falling over themselves trying to apply AI to anything, whether it really makes sense or not.
Out of the presentations that covered AI, I thought there were a couple that shared relevant points.
AI works by making stuff up
Dan Chuparkoff, a former technology leader at Google and Atlassian shared a couple of helpful explanations about product management and AI.
He noted that product managers “are the original prompt engineers” in that for years, you’ve been writing what you want from technology teams in requirements documents. If those requirements are great, you get what you want as the outcome.
That idea reinforces his observation that “AI will be incredibly valuable, once we learn to use it as a tool.”
He also explained in fairly layman terms how AI works:
AI is consensus driven. It hears the loudest voice in the room. So based on what you train it on, it picks the most probable next word. When it’s not sure, it uses statistics. AI generates things one word at a time.
In other words, generative AI are word prediction machines. Given a string of words, they try to figure our what the next one might be. And they rely on the data they’ve been trained on.
So AI is the ultimate embodiment of Garbage In, Garbage Out.
Keep the human in the loop
Yana Welinder, CEO of Kraftful, shared how her team has addressed the downsides of AI’s inherent tendency to make things up.
To counteract that, you need to keep the human in the loop and take a trust but verify approach.
It comes down to letting AI and humans each do what they’re good at.
Kraftful gathers data automatically, and then uses AI to crunch data, read the things you don’t want to read, and provide results to your team.
But it’s left to your team to look at the results and decide how you want to act on it. To help your team make that decision, it’s important that the tool shows how it came to the results, how it grouped information, and how it did its reasoning.
The tool also pays attention to how you control the process by changing inputs and including or excluding pieces of feedback around, and adjusts how it processes feedback in the future.
My take away - there’s a lot that AI can do, but just because you can use it for something doesn’t mean you should.
Collaboration > AI
You shouldn’t use AI for activities that are best done through collaboration.
In other words, don’t use AI to write your user stories.
The point behind activities like creating user stories or PRDs is to build a shared understanding of the solution amongst your team. The best way to do that is through collaboration amongst humans, not checking it over the virtual wall to some AI tool.
Involve the team in all aspects
Bukky Adebayo, Chief of Staff at Autodesk, and Rye Castillo, Design Lead at Render shared the story of how they did this when they both worked on the Waypoint team at Hashicorp.
Their story was one of finding ways to involve the team in discovery as well as delivery. Waypoint is a product for developers, so Bukky and Rye wanted to make sure that the developers on the team didn’t assume they knew what other developers would want.
Bukky and Rye built a virtuous discovery cycle where they included developers in a continuous cycle of activities that included:
Learning by talking to customers, and watching how they work.
Synthesizing their insights regularly as a team.
Sharing with the organization through internal marketing. Share weekly summaries with memorable presentations, and have open invitations to join upcoming calls
Get feedback - Welcome questions and feedback and feed that back into talking with customers
Bukky and Rye looked for ways to involve the entire team in defining and describing the solution as well. Before they wrote any PRDs, the team split into two groups
A group focused on who would use Waypoint
A group focused on would not use Waypoint
They took the results of the workshop and created persona trading cards that became a point of reference for their team.
The team split the PRD into a half that talked about the problem and a second half that talked about the solution.
Collaboration among product people
When you hear about collaboration on product teams, it’s usually in guise of product people collaborating with designers, developers, and stakeholders.
Clifton Gilley, VP Analyst for Product Teams at Gartner, explained the importance of collaboration between product people.
He pointed out as products get more complex and product teams scale, the idea of a single product manager handling all product management activities is no longer realistic.
He pointed out that different skills get you from Discovery to Design than what gets you from Design to Sunset. Not the same skills, mindset or people you work with.
So an answer is to use both product owners and product managers. For this to work, product owners need to be positioned properly as part of the product team and product managers and product owners need to have a peer relationship. That relationship needs to be collaborative, and there should still be some cross over.
Product managers will end up being 70% market/30% development teams while product owners will be 70% development teams and 30% market and customer exposure.
Thanks for reading
Thanks again for reading InsideProduct.
I hope you found these ideas helpful. If any of them resonate with you or you’d like more info, let me know and I’d be happy to go into them further.
Talk to you next time,
Kent