As a Product Owner, is “entrepreneurial” or “innovative” in your job description? Yeah, I thought so. But what does that even mean?
As I’ve mentioned before, the ability to ensure work is meaningful to the user-in-pain and the customer paying to resolve that pain (occasionally but not always the same person) is super important to the health and motivation of the engineers. The shorter the time between empathy and resolution, the more meaningful the work, the more likely the direct correlation with revenue, and the safer the jobs and projects of the engineers become.
The big “evil” business “side” in a large company doesn’t need any of that in order to maintain risk aversion and product agility. Cancelling a three year project before a customer saw it because a better project was two years in WAS their agility.
Congratulations on your agile transformation, but when you said “agile” you really meant lean concepts like “small batching” and “level-loading” and “systems thinking”. As a Product Owner, you must obtain a clear understanding around lean startup principles. That may shock you. Alas, the moment your team became an agile team, you became a new venture.
At scale, as a Product Owner overseeing delivery of your backlog, it is of tantamount necessity that you strengthen your relationship with your Product Manager. To the extent the Product Manager handles budget approval from the C-Suite on your behalf and builds up buy-in from your top customers, treat them like a venture capitalist with many connections in the VC/Angel community – and this is your first company. The expected return is 10X due to the extra risk. Many of them are having to let go against their will and trust that you know what you’re doing.
Within this context that you bear on your shoulders, the burden-of-proof that the budget can be trusted to the agile engines of production, you now have to proactively validate all learning about three things:
Product risk – The right thing was built to solve the pain of a large (enough) but narrowly (enough) focused group.
Market risk – The ability to build and continuously improve the viability of your product’s business model.
Customer risk – The ability to get the solution into the hands of the customer.
You are the single point of failure for information flow about your product backlog.
Project risk, as you once knew it, is gone. In fact, waterfall was the good ol’ days for the free riders and career passive observers among us. That was part of a bubble in the economy. SO long-lived that it caused no pain to investors, so you never heard it called a bubble. But the era of software-in-itself as a competitive advantage is gone. The fat shall be trimmed.
So no, you don’t have a deadline to track against but you do have the angel investments from your Product Manager(s). Also, you don’t really have “technical risk” anymore right? Come on, there isn’t much that you can’t build because most of us aren’t so imaginative that our requirements are science fiction. The risk that your estimates were wrong is so tertiary that some groups do away with it entirely.
No no no, YOU, my Product Owner friend, risk the loss of intrapreneurial “investor” confidence… the confidence that you know what you’re doing, mostly. Can good forecasting and transparency help? Sometimes. Unfortunately, some of us get promoted from T-Ball to the Majors with no notice that it even happened. We need a pocket-MBA and a time machine to make the new demands reasonable.
What can you do?
OWN your own destiny. The path to autonomy, mastery, and purpose is a purposeful pursuit of excellence in your craft. If you don’t love agile, you may start to. If your boss hates agile, you’ll win her over. But it’s on you to make it happen.
There are three “steps” to excellence in Product Ownership. Repeating these steps will take your abilities to the next level.
Step One: Establish Communication and Discovery Ceremonies
Agile transformations seem to fizzle at your level (the Product Owner). That’s because the Scrum ceremonies of the builders “under” you are well-established and grow from the ground up. They have become so commonplace that refusing the development team’s desire for a Sprint Retro seems just silly. The ceremonies that keep the team moving are established – the ceremonies you hold with your stakeholders, not so much. Without knowing the stakeholders and the meetings you already have with them, giving specifics here is hard. But – for whatever problem you’re having, looking outside your company. There is a vendor in the services industry that overcomes your challenge as a full-time business model. Prioritizing a longer term roadmap, creative brainstorming sessions, Lean UX workshops, Lean StartUp coaching – large companies have had the problems you’re facing for a long time. Look for a consultant, google what they offer, read blog posts, attend MeetUps. They are excited to talk about what they do. They know that they have to “out teach the competition” to be seen as the expert. Reach out to me for specifics. At the end of the day, borrow those workshop tactics and meeting agendas, get buy-in from each stakeholder, then establish a cadence for those activities.
Step Two: Pursue Cross-Functional Team(membership)
Never stop learning. Create a plan. Get a mentor or friend to share it with and if possible include it in your check-ins with your manager. As a Product Owner, you are the conduit between nearly every other function. Because the “development side” has begun fighting toward cross-functional teams, it’s critical you develop cross-functional communication skills. A simple way to get started is to ask people what they think works best about their jobs. An even more robust strategy is to list out all the job titles of the people you must successfully communicate with, check online for a job description, pick a skill or requirement and prioritize a backlog skills to learn. Should you master photoshop? No. But a few YouTube tutorials as you play with GimpShop (a free alternative) will be a real eye-opener. Remember this isn’t about becoming a jack-of-all-trades, this about mastery and excellence in your product innovation and delivery ownership role. Sharpening your ability to translate between specialists and clarify your intentions about prioritized effort IS your specialty.
Step Three: Define The Art and Science of Prioritization
I’m writing about this quite a bit else where. Check my blog posts, follow any links I gave and come up with your approach. If you need more specific answers, reach out to me.