The role of product management has evolved quite a lot over the years, especially in the era of cloud/SaaS. There are so many shifting dynamics, diagnosing the challenges product leaders face can be disorienting. We have spent thousands of hours with product teams, and in that time have seen a host of patterns that are not just common, they’re endemic.
In other words: No, it’s not just you, but those endemic challenges are likely yours to solve. On the plus side, the problems are so common, the solutions are, too.
How are you supposed to plan the next iteration(s) without feedback? Sure, the one thing you may know is that your customers aren’t using your app the way you expected them to, but do you know why?
Without the right inputs to prioritize the right user stories, you’re just guessing. Guesswork has, in the history of software development, helped exactly zero stakeholders.
Organizationally, this can be very difficult without the authority to draw a line in the sand, right?
A delivery team needs to define its process such that it engages stakeholders, focuses feedback, and pulls in the right metrics for the business to keep pace with what users (whether they are internal or external) are actually doing with the product, and what features will help them when they use it.
This is where customer development comes in. As part of the team’s process, someone (ahem, product owner) should be maintaining a healthy curiosity of who the customer actually is. The best way to exercise that curiosity is to talk to customers and learn from them without them catching on. If you can “trick” your customers or prospects into talking to you about your product as if they’re just chatting (and not “providing feedback”), you’ve mastered the art of customer development. Aim for at least one conversation a week.
Once that’s in place, it’s time to focus on gathering patterns out of your app’s usage. When you design a feature, its instrumentation should be considered. Build the feature so “How did they get here?” and “Where did they go instead of here?” are easy questions to answer.
Without the right organizational IQ in place, product leaders are often asked to answer to everyone. This isn’t just frustrating for them. It’s bad for the entire organization.
Siloed processes and interdependencies make one-click deployments impossible. The product leader’s priorities should be on the user. Instead, they’re often on solving and managing those interdependent decision-makers just to shove some new code out the door.
Second, this lack of value prioritization creates a leadership vacuum. Instead of focusing on what the product needs, product leaders have no real choice but to focus on reactive issues. This leaves the door open for other departments to take a leadership position. One common thing we see a lot: Sales leaders demanding a new feature and needing it “yesterday” to score a big deal. All of those competing priorities eventually come home to roost with the product teams.
These issues may not be impacting you negatively yet, but there’s no way the company will remain flexible and competitive if your product talent is focused on reactive internal issues vs. creative, forward-looking features and product excellence.
Accept that these issues aren’t going to be solved overnight, but you can solve big issues by standing firm on what you prioritize.
If you find yourself prioritizing tasks or technical elements of an entire solution, stop. Instead, prioritize user stories and features, giving preference to what produces the fastest and longest-lasting impact for your users. When and where you can, get consensus as early as possible to keep everyone focused on the next sprint. Ultimately, this is where your communication skills are going to be critical.
Managing the backlog and making sure the path forward is clear and transparent is job-one of any product leader. That doesn’t mean it’s easy. In fact, it’s overwhelming backlogs that often lead to decision fatigue, burnout, and frustration. Yes, a product leader is often tasked with juggling. That doesn’t mean you should feel like you’re always drowning.
How can you solve this issue if the backlog is so overwhelming that it’s impossible to orient yourself and the team? How do you decide what’s the most important?
Story mapping helps you view the backlog through the eyes of the user. We start so many of both our coaching and our development engagements by teaching the fundamentals of story mapping because it helps align the team around that context. With a story map, you can clearly see what’s important, and design a plan to build in pieces. That way you get value out the door faster and get feedback on your ideas sooner, meaning you spend more time delighting customers, and less worrying if you’re making the right decisions.
As organizations grow and bring on new talent, that talent may have differing or competing visions for the product. If you’re already suffering from organizational woes, putting more hands in the code or bodies in the process can destroy your ability to deliver a coherent product. If you find yourself waiting for other teams, or a product that feels like a patchwork quilt of experiences, you may have a problem with your org structure.
Product ownership is the glue that holds the strategic vision for your product.As you scale and grow, it’s a product leader’s (aka your) job to make sure the product doesn’t get lost in the mix. Grow teams around the product itself rather than around the steps necessary to make it.
Put simply: Resist the temptation to organize around skills like development, testing, or support. Doing so feels like it will make each of the functions more efficient but will ultimately grind product delivery to a halt as they lose sight of the forest for the trees.
You were hired as a product leader, but the organization doesn’t really understand that product and IT aren’t the same thing. They told you that you were going to be tasked with product ownership and/or management, but you spend your time chasing other people down to identify timelines, cost, and scope. Basically, you’ve accepted the role of a project manager with a fancy title.
Many CEOs simply don’t understand what the role of “product” is. If you’re reporting up to a CIO, that’s an even more complicated issue. If the organization is so small that you’re working with a founder, the education process could take time. That education process is far simpler than you think (and far easier than educating an entire Fortune 50 company).
Step one: You need some tools. Register for our free webinar and learn more about the role of product ownership.