Category Archives: Product Management

8 reasons my team is great (and keeps getting better)

Leave a reply

quote-you-cannot-make-an-omelette-without-breaking-eggs-proverbs-309526

My current eCommerce team is among the best I’ve ever worked with. In the past year, we’ve launched four mobile apps, re-platformed three eCommerce sites without any downtime at all, made major strides towards continuous deployment, and much, much more. (Even if you don’t know what any of these things are, you’re impressed by now, right?) Much has been written about building great teams, of course, and this is in no way meant to be definitive. Still, I want to share a few of the reasons my team has succeed so far (in no particular order), and why we’ll continue to get better:

1: Everyone on the team is a business owner

It would be an exaggeration to say that everyone on the team is motivated by our KPIs in the same way, or that each developer, user experience engineer, and Product Owner feels the same passion for driving revenue. Still, we do a lot of work to make sure each person on our team understands what drives our business, and the items on our product roadmap can come from any person or team. We understand both what we have to do and why.

2: We define our own priorities

Continuing on the above theme, our product roadmap is largely driven by the team. Because we understand what drives the business, we have the flexibility to work on the projects that are most impactful, in the order that makes the most sense. There are times we have to justify our priorities – and we review them with our senior executives each month – but we own the roadmap, no question about it.

3: We like to solve hard problems

Being intellectually curious is a big deal. Our team is smart, and intensely focused when it comes to finding sustainable solutions to big, hairy business and/or technical problems. Sometimes this leads to frustration – we don’t always have time to do things right, and we all despise increasing technical debt – but, by and large, our team strives to do things right, and we’re up for any challenge that comes our way.

4: We persist!

We like solving hard problems, and we don’t give up. When we can’t figure something out, we keep at it. Sometimes we wrestle with a problem for weeks – or months – before finding the answer we were looking for. Sometimes we need to try a lot of things before getting something right.

5: Our leaders push us in the right ways

When we need a kick in the pants, we get one. When we need some space, we get that too. From top to bottom, our company and team leaders understand that empowering the teams to do our best work is critical to our success.

6: We test and measure everything we do

Measuring allows everyone to see where we meet expectations and where we don’t. New functionality is AB tested until it “wins” and we’re confident we haven’t introduced new problems into the system. We’ve got dedicated testing and analytics teams, and our Agile development teams wouldn’t even think of introducing new functionality without their involvement. Of course, we still make mistakes, but when we do…

7: We learn from our mistakes

You can’t make an omelette without breaking a few eggs. Building and running our own web platform is hard, and despite all the great testing and measuring we do, mistakes are inevitable. Because we encourage continuous improvement and innovation, we also favor blameless post-mortems and retrospectives during and after all projects. These allow us to truly understand where we’re most effective and where we still have opportunity to improve. We’re going to make mistakes, but we really don’t want to make the same ones twice.

8: We genuinely like each other

Who wants to spend all week, every week, with people they don’t know or like? Not me. Work is a big part of our lives, but it’s not everything. People go on vacations, have babies, experience loss, and root for baseball teams (they often do those last two at the same time). And people who like each other are there for each other when they need support – in their work and in their lives.

We’re not perfect

If some of this sounds a bit aspirational, it is. My team is far from perfect, and we don’t always get these things right. We get crabby, and frustrated, and annoyed by each other. We argue, we have egos, and we break more things than we’d like. Sometimes we focus on the wrong things, and we’ve been accused of moving too fast. But the foundation of our team is strong, and our core philosophies don’t change.

Do any of these ideas resonate with you? Are you part of a high performing team? If so, what makes your team great? If not, how can you get there? I’d love to hear from you.

Moving from projects to products

2 Replies

Brian de Haaff, Founder and CEO at Aha!, writes lots of smart things about product roadmaps, Agile software development, and the role of product managers within an organization. Here’s an excerpt from The Product Manager v. Project Manager, published by Huffington Post last fall, explaining the difference between products and projects:

A product is what you are providing to a group of users. It can be anything: a physical product that you hold in your hands, a software application, or a service that you are delivering.

In contrast, a project is a plan with a series of activities that has a defined outcome and a fixed start and end date. The project is completed when that outcome is accomplished.

So, let’s assume that your product is a new mobile application. It might contain many projects before it is ready to be launched. These projects all have their own unique starting and ending points. The mobile application, however, is a product which will continue to be improved as long as it is being sold to customers.

Simple, right? Products last forever, while projects have a beginning and an end. Then de Haaff goes on to describe the roles of product and project managers:

What is a product manager? Product managers are often described as the CEOs of their products. They set the strategy, prioritize releases, talk to customers, and clearly define features. A product manager’s goal is to deliver a lovable product.

What is a project manager? Project managers oversee a fixed project from beginning to end. A project manager’s goal is to work with a broader team with a diverse set of skills and to complete a project on time and under budget.

I love these definitions because they’re so simple and straightforward, and I agree with them completely. And yet, practically speaking, it can be really, really hard to maintain such a clear separation between these roles and functions. Here’s what I mean:

Let’s say your product is website search, and your product manager is its CEO. She’s on the hook for, among other things, prioritizing releases and delivering a lovable product. How will she do that?

If your team works like mine, your product manager will have created a vision of some sort and a list of things that can be done to realize it. The vision will be long-term enough to be aspirational rather than tactical, and it’ll provide a north star by which your product manager can vet new ideas generated by product team members and others throughout the company.

For the sake of example, let’s keep the vision simple. Since our product is website search, our vision is:

To get customers to the right product faster than Amazon.

Now that we’ve got a vision, we can start putting a high-level roadmap together. Our high level roadmap shows that we’re going to work on search accuracy in Q1. Our more detailed roadmap shows this:

  • Move search to the cloud
  • Build user tools to improve backend efficiency
  • Automate the process of building shops
  • etc.

Hopefully you’re starting to see the issue here. Whether we call these roadmap items projects or simply “work,” once they’re identified, delivering them tends to become our sole focus. Other product management tasks, like setting the strategy and talking to customers, take a backseat.

Shifting focus

Although we’ve got business analysts, delivery managers, and user experience experts on each product team (not the typical Silicon Valley approach, I know – I’ll discuss this more in a future post), our product managers often have the clearest sense of our overall strategy and business context, and they’re the ones who are on the hook for delivering the business value they promised. That means our product managers are personally invested (which we want them to be), and that keeping them closely tied to our projects is critical to our company’s success.

Our challenge is this: how do we keep product managers involved in each effort while still protecting their time for things like strategy, talking to customers, and long-term thinking?

Here are a few ideas:

More context for everbody
Product managers can’t be the only people on the hook for delivering business value. We need to work harder to make sure each member of each product team understands what drives the business and has a clear understanding of what success looks like. We need to work more collaboratively and share common goals. Beyond sharing ownership of the project’s goals, everybody on the team needs to understand their role in the context of the overall business.

Expand job definitions
Once everyone’s got enough context, delivery managers, business analysts, and UX experts can more fully own their roles in each project, moving product managers towards a more strategic, consultative role – and out of the role of “gatekeeper.” This can be as simple as a delivery manager making the call to delay a release without consulting with the product owner. (Informing? Yes. Asking? No.) To make this work, product managers have to give up some control, which is a big challenge.

Reward product managers for being strategic
People tend to focus on the things they’re rewarded for, so if we want our product managers to more effectively empower their teams, we need to reward them for things like providing context, delegating responsibility, and thinking long-term. We need to make it okay for other people on the team to be on point sometimes, and we need to provide the training and structure to ensure our products won’t suffer for it.

Protect your peoples’ time
Providing context, training people, thinking strategically, and talking with customers all take time. We need to acknowledge that time is a limited resource, and we need to actively, continuously, help our teams prioritize their work. We can’t tell our product owners that strategy is important without figuring out how to give them time to do it.

Physically separate the team
Part of the reason our product managers get sucked into every small decision around requirements, timelines, and user experience is that they sit directly across from the people working on those things. What would happen if we physically separated our product managers from the rest of the team? Might 20 feet of distance change the dynamic considerably? Might less collaboration lead to more empowerment?

Get feedback and revisit regularly
Change is hard, even for people and teams that do it well. Protecting people’s time, shifting responsibilities, providing context, and expanding roles make people uncomfortable, and sometimes some of these things just won’t work. If we’ve done it right, we’ve created an environment in which our teams are comfortable telling us what works and what doesn’t.

Even more than that, we need to actively solicit input, we need to be open to it, and we need to be willing to revisit our assumptions. The things that worked for us last year, last month, or last week may not work for us today, tomorrow, or next year. Like building great products, building great product teams requires time and focus.

Building trust

I’m a control freak by nature – I like to see everything my team is building, weigh in on the user experience, gather direct feedback, and provide my own. In my experience, there’s only one thing that cures this tendency: trust. In order to be comfortable that I don’t need to weigh in on every small decision, I need to trust that I’ve got the right people in the right roles, and that they have the skills and context they need to make solid decisions and create great products. They don’t need to make the same decisions I’d make, but they need to make educated decisions that they can defend.

Moving our product managers from project to product requires an enormous amount of trust – trust that teams will make the right decisions, trust that each person can handle their part, and trust that we’ll have each other’s backs when things don’t work out. Building that trust requires that we create an environment in which people can learn, experiment, and change. It requires that we allow our teams to challenge each other and to be challenged. It requires that we give every person on the team what we think we need in order to be successful, and that we understand that sometimes they’ll fail anyway.

How does that sound, control freaks?