Product Owner — Product Manager
The beating heart of a digital company is its product organization.
For tech startups, the company is indistinguishable from its product since the organization is built around that product from Day One. Hyper-growth startups find success a double-edged sword: they must prevent bursting at the seams while continually transforming a product organization to stay one step ahead of double-digit growth.
Legacy enterprises start at the other end of the spectrum. Already large, enterprises are challenged with the transformation of heavy IT organizations into the nimble hearts of living digital businesses. Their struggle is to become more like startups: to go from massive projects that support operations to smaller products that are the operations.
But both seek the same end goal through digital transformation: to build coherent product organizations that propel the business forward.
My good friend
recently accepted such a challenge at Yieldmo, a Series C startup, where he manages the product organization. This is his story as told to me and Eric Schmalzbauer.
Day Zero
Josh: “When I started, I noticed that we were very unstructured as an organization. We were most like a hive, constantly swarming around whatever needed to happen. While that had worked really well for Yieldmo in the past, it was starting to show its cracks.
“To establish trust, I had to have a very quick win. We rewrote the Android SDK from the ground up and wound up rewriting most of the iOS SDK as well. In three months we had a functioning product that’s gone live and almost all of our premium publishers use it without problems. So that’s cool. That’s what allowed me to then say, ‘We need structure as an organization in order to continue to grow and build great products.’”
Crawl, Walk, Crawl
Art: “How did you think about the process during this phase?”
Josh: “Where I’ve seen it be successful, you have to crawl, walk, crawl, walk. Start with the minimum amount of process, have clear objectives, try something, evaluate the data after a set period of time, and make changes based on that data.”
Art: “It sounds like you are saying, ‘I’m not going to set the endpoint. I’m going to set the early points and just try to be directionally correct.’ Why didn’t you set the endpoints first and work backwards from that?”
Josh: “What I’ve seen is that continuous improvement doesn’t work if you’re continually trying to improve continuously all the time. You have to stop. Try some shit. See if it actually works, and then reevaluate. I always come back to the design principles and process. Define autonomy, define alignment, and make sure people understand what’s not on the spectrum. Trust the process.”
Art: “It sounds like you didn’t care what everybody did.”
Josh: “I cared about what’s useful. I looked at Google and Facebook and talked to those guys. But when I talked to some people at Spotify, I realized what we actually already had most mimicked Spotify. I learned that a lot of their stuff would apply at Yieldmo. So I just borrowed wherever I could.”
Art: “That was smart. You basically went to the shortest increment to a transformation from your existing culture without being religious about the model.”
Josh: “Yeah. At Yieldmo, we took most of the Spotify model from a principal perspective. We organized around the principles of autonomy and alignment. We set up squads. Squads are cross functional teams that are autonomous. Each squad has a mission and does whatever it needs to do to get that mission completed.
“We’re punching so far above our weight; I think the Spotify model requires a massive amount of organizational maturity to pull off well. So, there are differences between Yieldmo and Spotify by design.
Product Playbook v1.0
“I took the total traditional consulting route resulting in a playbook for the product organization. The playbook looks at people, process, and technology, and then specifically calls out the continuous improvement piece, which is exactly what the engineers needed. But it is also pushing them since they know what continuous improvement actually means.
“The engineering response was really helpful because everyone else said, ‘It’s so corporate. This is such big company bullshit,’ or whatever. I was like, ‘Cool. Yeah, very valid feedback, guys. Let’s commit to these changes until Jan 1 or April 1 or whenever the next measurement point is.’ From non-engineers, the phrase I heard more times than I can count was ‘We’re moving slower.’ I asked, ‘Well, are we or are we actually moving?’
Roles-based vs Hierarchical Organization
“We’re a roles-based organization. That allows us to depend on people to get tasks done. Roles have decision-making rights. Roles have to be able to deliver on their responsibilities, so they have to have the final say for what they’re responsible for.
“Roles are not titles. They’re often the same and almost always correlated. With us though, product owners typically have titles like VP of product, SVP of product but they do not have to. Chris, for example, is a Director of Engineering. That’s his title. But he plays a product owner role. Making titles and roles separate is tricky, requires some organizational overhead, and can be confusing; however, for us, it lets people try new roles with critical responsibilities without having to change their titles. This flexibility is really helpful and gives us more organizational flexibility.”
Product Owner, Product Manager
Art: “I’ve been describing the product manager as a CEO of the product but I think your characterization of the PM as the COO of the product is much better. By comparison, a product owner is really the CEO of the product, but the CEO in more of a flat organization.”
Josh: “Teddy has the title of Yieldmo’s Head of Product and plays the product owner role for Yieldmo. My role is the PM. Teddy should always be focused on what we’re working on as a product organization whereas I make sure the trains run on time.
“Some of the best product people here are the nontechnical ones. Many of our product people are working on incredibly technical products. For example. I was the VP of product here for the SDKs. I know enough to do a code walkthrough. I understand Objective C, Java, object-oriented programming, but I could never step in and touch or write a line of code.
“From Pivotal, I had this vision of this dynamic tension of pairing; not a developer pair, but a product owner-product manager pair as the key nucleus of every squad. So every viable squad needs to have someone playing the role of product owner and someone else playing the role of product manager.”
Art: “What are the characteristics of a great product owner?”
Josh: “If you really look at it, the product owner’s job is to really understand the problems and the business, build prototypes, and test them to provide what product managers need to build. The product owner‘s job spans from research to operations, creating, launching, and support; product manager’s job is the same general categories, but mostly focusing on what needs to be built and how.
“The PO defines roadmaps and sets product priorities. We use this idea for product councils as one of our more formal communication mechanisms to key stakeholders across the business. In every squad, the PO has to run a product council and is responsible for managing it. That’s where they cover the roadmap, what we do, where things are going and feedback.”
Technical Product Managers
Art: “Have you ever thought about implementing the TPM role here and why or why not?”
Josh: “The product manager is technical enough and curious and interested, but understands that at the end of the day they couldn’t have coded it themselves.
“I believe that there are great technical product managers out there, but the risk is that they want to get their hands dirty and then mess shit up. They can let down their product responsibilities when they try to get into code. Every time they do, they risk messing with the team dynamic.”
Process and Tools
Art: “Tell me about your sprints.”
Josh: “Some squads have tried one week and that did not work out. Some are not running sprints and that’s fine.”
Art: “ Is there a tool that is being used commonly across the organization? What do you use — spreadsheets?”
Josh: “There has been a lot of conversation about tooling. The ultimate answer was autonomy. You choose the tooling you want. Now, the hope is that squads will eventually come to something like Jira. We have a couple of key holdouts on the Trello train and, honestly, they have hacked the shit out of Trello to the point where even I’m like, ‘Well, yeah. That’s pretty good.’
“We have built structures and process for constantly sharing across squads. So tools and process may be tried in one squad then shared to others. I have seen a lot of practices develop organically here and then spread to other squads. I think it is the best way to spread process rather than dictating too much.”
Measuring Progress Means Measuring People
Art: “How do you know when you’re making progress?”
Josh: “We do a self-scored, private scorecard exercise. We went through every roadmap for Q1. We measured how they did, whether they achieved their outcomes, whether they hit their definitions of done. We also did a squad survey around alignment and autonomy It‘s fun for me because it opened up all sorts of conversations. It’s such a beautiful way to do what is normally very painful.”
Art: “Are PMs and POs measured as individuals or as leaders of teams?”
Josh: “We set quarterly OKRs (Objectives and Key Results) for the entire product team. Each squad sets a roadmap against the OKRs. The product owners choose which key results they believe they can impact the most. Then measure success metrics. Build maturity.
“We’re starting to hit the limit of what we can do without real customer feedback. We don’t always have to do what the customer says, but at the same time, we absolutely have to listen to them and incorporate their needs.”
Functioning Product Team Makes a Happy Sales Team
Yieldmo SVP of Sales, Chip Jessop:
Art: “How has the new product organization affected you? What results are you seeing after three months?”
Chip: “One of the most immediate things is that we are doing a much better job getting ahead of product rollouts, getting my team closer to feeling product ownership, accountability, and a key part of the launch team.
“I am blown away. What I’m loving is that people are starting to just pick stuff up. It’s very much a viral sense of practice, evolving and iterating. It’s cool.”
