Melissa Perri

This product owner role did not emerge from product management as we know it today. It was a way to help the developers prioritize what to work on.

If you ever see somebody with a CSPO on the end of their profile, it's a certified Scrum product owner. It's typically a two-day workshop that they went to and then got certified.

I guarantee you there's a ton of tech debt they could be working on. You don't have to scope that out. Let them choose what's the most important thing.

The way different story than I prioritized backlog and I shipped it off to developers. Take it a step further - who are your customers? Did you go out and talk to them?

You have to make sure that it is thought of at the C-suite. What some organizations do is go, 'Oh, no, that's IT work. Let me push all the software strategy down.'

A lot of large companies turn to Scrum or to the frameworks, and it's because they traditionally didn't grow up building software.

Even when I didn't have that role or responsibility or that scope, I sat there and I still imagined what I would do if I was in their position. And I think that's powerful. Pretend you're the CPO. Would you do something different? What would you do?

One of the biggest issues I see in organizations is when executives all have different goals, and they're not aligned on the same goals for the company. So it's like, sales teams over here are like, no, our goal is new logos. And you're like, cool, but in what markets, and how is that prioritized against what we're building from our product roadmap, and why is this not in sync?

If your executives and your board are telling you, I don't really know what's going on in tech or product. I have no idea if we're achieving our goals. If your executives don't know what you're doing, that's a big problem. So that's usually the sign, to me, that we need that.

I would try to ladder that up myself into a strategy and see if it was connected. And if it wasn't connected, that's telling me somebody's not formulating the strategy and deploying it down.

A good test is you go to all of your teams, and you ask them what they're doing and why, exactly what I was talking about before. And they all tell a similar story. We're working on X, Y, and Z because it goes into this initiative, and it causes this type of value for these customers, which, in return, is going to get us this business value.

I've met a lot of organizations that think most of their issues are in the training of their people. And 99% of the time I see that it's actually in the way that they're setting their goals and deploying their strategy. Because once you train those people, they have no context on what to work towards.

Really, strategy always comes down to asking the questions about how can we win, how can we get further to the goal, which is the vision. But it's also keeping into context of where we are now and what we're able to execute on now.

We take all the information we can, we make the best possible guess to go in one direction, and then we just keep reevaluating it to make sure it's the right direction. And if it's not, we pivot.

A lot of times, we just don't go and talk to other departments. And they have a wealth of knowledge. And we've got subject matter experts sitting in certain places that can fill you in on how the market's moving, and what things are happening there, and how people are innovating.