Tag Archives: product development

If you don’t know why you’re doing something, stop and ask!

Leave a reply


Picture this: after a long day at work, you arrive home (or close your laptop, as the case may be) and your partner is frantically packing their suitcase. “I’m leaving,” they say, before exiting the house, getting into the car, and driving away.

Alone in the kitchen, you realize how little you know about what just happened. Is your partner dealing with a work emergency? A family crisis? Do they need to get to a store before it closes? Did they just … leave you forever?

Regardless of the answer, your partner is gone. But without context, it’s impossible to know how to respond. Should you call your family? Start cooking dinner? Pack your own bag? Create a Match.com profile? How can you solve the problem if you don’t know what it is?

This happens at work all the time

Fortunately, this doesn’t happen too often in our daily lives – if it did, we might find more communicative partners. But somehow this scenario plays out at work all the time, every single day. Here’s an example to help illustrate my point – apologies if it hits too close to home:

Jane is a product manager, whose boss tells her to “remove the banner from the landing page immediately.” Jane understands that this “request” is urgent, and she chooses not to irritate her manager or slow things down by asking lots of questions. The request is clear, so Jane writes it up and injects it into the sprint. The banner is removed within the hour. Everyone is happy – for now.

Three days later, the team has enough data to assess impact of the change: as a result of the banner being removed, landing page conversion has improved by 50 bps, but nobody (literally nobody) takes advantage of the special offer, which was intended to incentivize multiple purchases. We no longer have a signup problem – now we have retention problem. Why?

As it turns out, Jane’s boss wanted the banner removed because it was covering up the email field, creating enough friction to negatively impact conversion. Removing the banner altogether was an extreme response to a simple problem, like using a sword to cut a fingernail. A more nuanced approach (like repositioning the banner instead of removing it) could have achieved both of the company’s goals. The problem was that nobody knew what the company’s goals were: no one offered them, and no one asked.

Every company I’ve ever worked at employs smart, highly motivated people. As I pointed out in my post about aligning product and engineering teams, smart and motivated people are used to delivering what’s being asked of them day after day, and they’re very good at it. Still, they crave context for their work, and they’re ready to use it to solve real business problems in smart ways. That’s good news, and there’s more: effective leaders actually want their teams to think this way. Why treat a chronic illness if you can cure the disease?

Curing the disease

Curing the disease isn’t as easy, but you can make progress today. Here’s how:

Create a culture of empowerment
If you treat your people like order takers, that’s how they’ll behave – until they find new jobs. Creating a culture of empowerment requires that we spend time thinking about problems and opportunities before proposing solutions, and recognizing that many problems have more than one perfectly acceptable solution. It means taking the time to discuss goals and provide context instead of telling people what to do, leaving space for questions, comments, and alternate approaches. There are lots of things a team can do by taking a bottoms up approach, but creating a culture of empowerment starts at the top.

Spend more time truly understanding the problem
In the wise words of Abraham Lincoln, “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” I haven’t done the math, but my years of experience tell me that every hour spent providing context to engineering teams saves between 2 and a million hours of development time. Don’t fall for the mistake of thinking hands on keys is where the magic happens. Give your teams plenty of time to understand what they’re doing and why, and they will amaze you. As you may have heard, slow is smooth, and smooth is fast.

Go out of your way to make people feel comfortable expressing their ideas
A point of view might be worth 80 IQ points, but you’ll never hear one unless you make it clear that’s what you want. In most work situations, the sad truth is that it’s safer not to argue with the boss. If you want your people to challenge you with new ideas, questions, and solutions, you have to let them know explicitly. And if your company is entirely remote, you need to remind them regularly, because it will take longer to sink in.

If you don’t know why you’re doing something, stop and ask!
The suggestions above are aimed at team and company leaders who want to create a culture of context. But once it’s clear that asking questions is okay, the responsibility belongs to everyone. I’ve seen lots of people and teams deliver the wrong work because they didn’t want to “bother” someone else, even with something as innocuous as a Slack message. If we’ve ever worked together, you’ve heard me plead: do not suffer in silence. And yet, it happens all the time. If you don’t have what you need to deliver great work, it’s your responsibility to get it. In most cases, the people responsible for providing context will think they already have, or don’t know what you need. Assume good intentions and set yourself up for success.

What do you think?

I once worked at a company that refused to provide context as a matter of policy: they felt it was more efficient for leaders to turn decisions into requirements, and to cascade those requirements to individual contributors. The way they saw it, context led to discussion, and discussion led to debate, and debate slowed things down. Simply put: they wanted less talking and more coding. You won’t be surprised to learn that this resulted in frustrated teams and failed projects.

Still, I’d love to know what you think. Have you worked at a successful company that operated differently? If so, how did you make it work? If you agree that context is important, how have you made it part of your team or company culture? Have you tried any of the suggestions above? Do you have any of your own? Please let me know!

“Healthy tension” between Product and Engineering? No thanks, I’d prefer alignment.

2 Replies


I remember the situation like it was yesterday. I was leading the Product and eCommerce team for a large retailer, and Black Friday was only four weeks away. At our October check-in with the executive team, I’d told the CEO we’d be delivering several features to improve checkout conversion, which would increase revenue by as much as a million dollars.

I wasn’t just trying to make myself look good. Like any competent leader, I’d made the commitment only after discussing the situation with the appropriate teams, and my partners in Engineering were in lock step. Within a week of my meeting with the CEO, though, things had changed. During a load test, a scalability issue had been discovered, and it would require the full focus of our Engineering team.

The Engineering leader asked what I wanted to do. Should we continue to focus on the features we’d promised, or pull the team off of feature development to focus on system stability? I don’t remember it being a hard decision. “Those features aren’t going to do a lot of good if the system is down,” I said, “let’s shore it up.”

Healthy Tension?

A lot has been written about the importance of “healthy tension” between Product and Engineering teams, and on the surface, it makes good sense: if one team is focused on building new features and the other is focused on code quality and stability, the tension between them might encourage discussion and debate, and neither team will lead the company off a cliff. In fact, the theory goes, this “healthy tension” might lead to compromise, somehow delivering the best of both worlds. I disagree.

The problem, I think, is in the assumption that Product and Engineering teams inherently have different goals. They don’t – or at least they shouldn’t. Both teams are responsible for the growth and stability of the company, for revenue and scalability. Neither can succeed without the other.

When we assume otherwise, we sell each side short. Any good Product Manager will tell you there are times when addressing technical debt is the smartest use of development resources, that the push for new features needs to be balanced with a view towards system health. And any good software engineer will tell you that the world’s most performant system is useless unless it drives business results, that sometimes it’s worth taking on tech debt to take advantage of a market opportunity.

Think of it this way: if you were building a house, you wouldn’t expect your architect and your builder to simply hand off their work, you’d want them to collaborate around shared goals to make sure they were in agreement. A good architect would never design a house that couldn’t be built, and a good builder wouldn’t build a house that was poorly designed. We should expect the same from Product and Engineering teams.

A smart and logical group

“At a basic level,” according to this AHA.io blog post (and many others), “product managers should tackle the ‘why’ (product strategy) and ‘what’ (features) for the product. Engineers should determine the ‘how’ — the technical implementation of features.” While this may be true at a basic level, it’s not the way great Product Development teams work.  In my experience, great teams – the ones that are most engaged and produce the best work – are the ones where Engineers are involved in defining the “what” and Product Managers weigh in on the “how.”

This is because Product Managers and Software Engineers are often among the smartest, most logical employees a company has, and they tend to be very capable of both understanding business goals and coming up with creative ways to achieve them. When we neglect to give our teams the full context of what we’re trying to achieve, we make it harder to solve the problem, and also to commit to the solution.

This takes time up front, of course, but when a Product Development team has conviction that they’re solving the right problem in the right way, they can move fast with trust and confidence. And when something goes wrong, as it inevitably will, the team members have the context they need to address the issue in a way that still meets the goal of the project.

Product Development teams

I’m not saying there’s no place for “healthy tension” at a company. As this Product Plan article points out, “there’s a reason you don’t see titles like Vice President of Innovation and Compliance. A little tension is good.” For a company to be successful, it needs to have people with different perspectives, and there needs to be lively debate.

But tension between departments is different. I prefer to think of Product and Engineering teams as combined Product Development teams, making sure they’re in lock step as it relates to goals, strategies, and priorities. As this Martin Fowler article points out, “aligning these two disparate organizations [Product and Engineering] into cohesive team units removes organizational friction and improves time to value.”

I’d encourage all of us to adopt more of a Product Development mindset, acknowledging that Product and Engineering teams cannot thrive unless they’re joined at the hip.

A note on org structure

In my current role (as in my last few), I’m responsible for Product Development, which includes Product, Engineering, and Product Design. Despite my own experience, I don’t have a strong bias for all of these functions reporting to a single leader – I’ve worked with great CTOs and VPs of Engineering, and without the right leader, combining teams can be a mistake. My point in writing this post is not about having the right org structure, it’s about having the right mindset, which can exist in any structure.