Planning, resources, and communication are incredibly important when multiple teams are touching and driving the same product. There are some advantages to seeking results with a product you don’t actually own. But how many cooks in the kitchen are too many when it comes to shared goals? Raquel Hirai-Hadley, Product Lead at VOGLIO, a Seattle-based marketing agency, discusses proven tools for product strategy to tackle the most common product ownership issues.
Join us for new conversations with leading product executives every week. Roll through the highlights of this week’s event below, then head on over to our Events page to see which product leaders will be joining us next week.
Join us at our weekly Speaker Series events to engage with product leaders in your own community and gain insights on how to accelerate digital transformation.
On Goal and Metric Misalignment in Product Strategy
When thinking of ownership types and issues that arise, Raquel lists them in four categories or “buckets”: goal and metric misalignment, communication inefficiencies, capacity and resource conflicts, and fundamental control. There are a few ways you can tackle these issues. First up: goal and metric misalignment in product strategy.
“One of the first best practices that I’ve learned throughout my career is to make your goals more visible. It’s okay for you to be repetitive when it comes to goals and metrics, but find all the opportunities that you can to reiterate your project goals. Two favorite ways of doing this are having the UX and UI designers include a screen in our high fidelity mockups that basically has goals and any important considerations … The other way is talking about that in stand-ups as you are reviewing the project and reviewing the progress. … I think it’s really important to sit down and review the goals with stakeholders. That’s something that we always do at the beginning of our project to ensure that there is alignment there.
Next, treat metrics as first-class citizens. Sometimes, in some projects where the data was kind of treated as an afterthought, there was a lot of work that was put into the UI, the design, and the development portions, but, not so much on ensuring that the data was being captured correctly. The metrics basically have to be as important as the UI design and the development. You can improve what you can measure. … Many of us have to rely on Excel, or some sort of spreadsheet to present data. If you can invest in something a little bit nicer, it’s easier to share, it’s easier for others to have access. … The more documentation that you can have on your data, the better; you will need that, especially when you’re doing those year-over-year comparisons.
Instill a data-driven culture. The way to think about this is, you want to be your salesperson for data tools. The more data you have, the less ambiguity you will need to deal with around direction and ownership. This is going to not be about your take or another take; it’s going to be about the users. Invest data tools as much as possible.”
On The Importance of Fixing Communication Inefficiencies
Communication inefficiency is the product strategy team issue that needs to be the top priority or the second from the top. By being intentional with all your communication, whether it is one-on-one, meeting topics, or other ways, it helps to streamline any product strategy issues that pop up.
“Establish a communication plan. If you haven’t already, be more intentional about your communications and creed cadence. You can create a matrix of status types or issues to be addressed. It really doesn’t need to be anything fancy. …Another one is also very simple: a periodic review. We are all used to all the meetings we have in our calendar; Google Calendar keeps showing me my average of 20 hours of meetings per week, which is crazy. It’s very important for us to just do a review and say, “Is this meeting still effective? Do we really need those hours, or can we reduce the audience rate and just really make good use of that time?” Then with that comes the next item, which is related, which is to really use meeting time wisely. One thing that really helps to build your relationship with your stakeholders is trying to prioritize the stakeholders in the meeting instead of prioritizing a topic. If you have a meeting, and you know that your developer is going to be there for that full hour, just try to take care of the thing that the developer needs in the first 10 minutes and let them go.
Next, show what you mean. … This is about being redundant, being repetitive, confirming meaning with people. It is very helpful to show alike features to clients when I’m teaching a solution for a project or just to get them inspired. … Pull existing pages as we’re talking about it, something everybody looking at the same thing together. … Bring the user perspective as often as possible to the discussion. Bringing the user perspective is particularly valuable when there is disagreement. Some person wants to go this way, the other one wants to go this way, and they’re starting to feel tension. That’s when you come in and say, okay, so if I am a user, [insert person], I’ll be doing blah, blah, am I right? Right. … This really helps like to bring people together, and then be looking at the problem from the user’s perspective.
The last one is building relationships, one-on-one time. So we found that it’s very helpful to create these more meaningful relationships with our important stakeholders: really having that one-on-one time to have frank conversations without the pressure of having your manager or maybe your direct reports attending it, really spending time to learn about personal goals, learning about each other. Also: group recognition. Make sure that you are giving credit to people all the time, small or big contributions, it really doesn’t matter, but just to celebrate their accomplishments and also help build that relationship.”
On Category and Resource Conflicts Within Product Strategy
It could seem like everything is doing great — until it isn’t. This is when resources are stretched thin and everyone is battling for what little is left. The previous two buckets come into play here to make this one more successful.
“One of the biggest issues around product ownership is their resources battle. People tend to think less about product ownership problems when everything is going great. ‘I have my pod, my project is progressing, it’s great. And then there’s the other project or product owner, and their pod doing great,’ but then when you get to a point where it’s like each sprint matters right now, everything needs to happen. It’s then you have some things to think about. The first one is very important when it comes to capacity planning, what I call apply systems thinking. Don’t forget your user flows. Thinking holistically about your product will obviously improve the UX but this is also going to help you plan your resources more adequately. You can do way many different things to look into the user flows. You could impersonate your user and use the tool, you can check nav summaries, you can spend dedicated time just to review the features on your site. … There are many different ways that you can do this, and it is important.
The other one is about the small change myth. Really be alert when you hear ‘Oh, this is just a small little change that doesn’t need a mock.’ My team gets very stressed out but when they hear that, and it’s true because I think that in order for this to work, you really must be a repeatable and very isolated task to not impact something else. Anticipate issues and patterns, think about patterns and project types, and if we experienced similar issues with certain teams, features, and vulnerabilities. Is there anything that I can do to reflect on the past and to prevent or anticipate an issue? The other one we do often is capacity planning. Capacity planning is really hard because things change all the time, but it’s important to have something that shows expected percent, that 10 times per initiative in the next x weeks or months, whatever the timeframe is relevant to you.”
On Fundamental Control
Does fundamental control matter? Raquel thinks so, to become an advocate for your product will bring more success to it. She compares it to parenting and how we interact with our children.
“Treat it as yours. You may not own the full product, but you should treat it as if it was just yours. Be the user advocate. Think about the benefits and the value to the user on this sale, obsessing over the code, and the story that needs to get done. We want to think hard and holistically. … The way to think about these is becoming an advocate for the user the same way that we as parents are supposed to be advocates for our children. We need to be able to address their issues, even the ones that may not be aware of, may not be able to communicate properly, or may not even be making meaning of yet. That’s very important.
The next point is around working collaboratively, and the point is to highlight empathy. Empathy is a very important concept. In an article from September on Forbes, it talks about empathy being one of the most important skills for a leader. This is all based on research that shows more people are feeling anxious. More people are depressed. There has been so much that happens this last 18 months.
The next one is around questioning. You know, if you disagree, or if you’re unclear on the request, on the reasons for a request, or get a change request feature, something that got deprioritized, ask. I highlighted five whys because that’s a pretty simple problem-solving framework … that really kind of helps you get to the root cause. Sometimes you don’t really need to go all the way to the five whys to get to the root cause, may need just three, but it’s just a way of really trying to understand what’s happening. In the end, the user actually owns it. I am pretty sure that you can relate to senior leaders talking about their gut feelings. I’m sure I’ve said this myself, so I’m not going to pretend I didn’t, because I’m sure I said it. Sometimes leadership has wonderful instincts, and sometimes they are very wrong.”