What's the role of Engineers in Product Strategy?

I started my career in a tiny startup that eventually became a tiny software house. There we each did everything. Sold projects, talked to customers, defined scope of what we had to do and how that related to what we needed to build, planned sprints, wrote the software… you get the gist. This is, in a way, terribly inefficient. Still, it hammered something in my head: When we’re building products, every single type of decision–be it business, design, engineering–affects the product strategy, and product strategy affects what we’ll actually build. A corollary to that is: we’re all responsible for Product Strategy.

Fast-forward a few years, and I joined QuintoAndar, where we have more clearly defined roles. Here a team usually has people with complementary skill-sets trying to solve problems and evolve our products. We have Designers, Product Managers, Software Engineers, Data Scientists, etc., all within the same team. This is intended to make the team more autonomous and allow them to collaborate as an early-stage startup. This was great to me because I could finally focus a lot of my time on my specialty: building software. This focus was a blessing. It made the team more efficient, more effective and made us grow faster in what we do.

Building Software is a craft. It takes time, focus, and creativity. We frequently do it in a flow state, and we Engineers are usually passionate about honing that craft. So it’s only natural that when we focus on it, we’re drawn deep into our world and forget what’s around us. It’s almost addictive being that focused. So much so we can forget the truth that we just talked about: we’re all responsible for Product Strategy. If we tunnel focus on building things, we can create Silos.

This doesn't use the multi-disciplinary team like it should

Sure we can present our work to one another. Create flashy visualizations and share learnings. Communication is key, after all. But, if we each just take our work and put it in the hands of the next person, we’re effectively working as a small waterfall. When we put ourselves in these siloes, accountability goes downhill.

This is usually the cause when we see Engineers complaining that Product Managers don’t give them enough time to build solid architecture, to trim out technical debt. When Product Managers start to see the team as slow or “too Junior.” When the Designers start to feel that they don’t have agency. Silos kill accountability.

Don't assume the worst. Your teammates usually care about you and and about the users

Before we go into what the role of engineers actually is, let us start from a shared understanding:

1. People do not want to fail. I’ll repeat that. People do not want to fail. They might disagree with us on what we should build and how we should build it or even when we should do something. But they do not want to fail.
2. As smart as you may be, **you’re probably not surrounded by idiots–**it also makes you look quite arrogant when you say this. If we start on the assumption that “he won’t get it” or that “she doesn’t care,” we will never get to a solution.
3. Product Strategy and Execution are everyone’s responsibility: If we don’t get time to build things right, it’s the whole team’s problem. If we fail to execute, it’s the whole team’s problem. If we’re swamped in technical debt and can’t build anything new, it’s the whole team’s problem. So we must own our part and take professional risks when necessary. Anyone can have the best ideas.
4. The Customer comes first everything else comes second. If we worry about our egos more than we worry about getting things right, we’ll build the wrong product. We can’t make decisions based on the shiny new thing we want to work with and not on what’s more effective.

We’re only leveraging all the power of a small autonomous team if we work collaboratively and everyone is directly involved in all steps. This doesn’t mean going back to how I built things in my tiny software house. We still have specialists and still rely on each other’s strengths. What it does mean is that we take ownership. We don’t let anyone in the team set us to fail.

We need to support each other throughout the whole cycle of building the Product

So, after all, what’s the role of Engineers in Product Strategy?

When we ask this question, the most common answer revolves around Technical Debt. Which is certainly something important, but there’s a lot more to that. Collaboration is at the center of our role here. The programmer hidden in a cave receiving assignments and shipping them is thankfully a dead concept. Our role is:

Discuss, Participate and understand thoroughly the outcomes we’re going for. We need to be in the room and disagree until we can commit. Do not half-ass or say “I told you so” later. It’s also our fault if the team goes on to pursue an outcome we don’t trust in a way we don’t think is the right one. It’s way easier to sit out and avoid hard conversations. Confirmation Bias is a thing, and people will try to defend their points of view. But that’s only more reason why we should bring opposing views and challenge what’s being discussed. But what if I’m not included in the discussions? Well, have you asked to be included? If you have been asking and still are not, look for somewhere else to work.

Do not commit to deadlines we cannot meet. Understand when we can make a high-integrity commitment and when we cannot. Help the team draft experiments and prototypes that give us more knowledge and buy us time to make the most critical decisions when we have more information. This could be included with the last point, but I’m singling it out because it’s one of the most common ways we err.

Communicate clearly during execution and adjust strategy. While we’re building, we make several decisions that affect quality, documentation, and timeliness. This is even more reason for us to understand the strategy fully. While these decisions are clear to us, they’re not clear to the rest of the team members. We need to make sure to communicate emphatically whenever things change. For example, the team might not be on board with us shipping a product that is not accessible. Knowing that we can’t build it to be accessible in the current timeline allows us to either change the schedule or reduce the scope. But only if we communicate that before it’s too late.

Feed data and insights back to the team on how big issues and opportunities really are. Rewriting an application is way easier when we’ve shown people that it’ll make us unlock a lot of value or capacity for the team. This means understanding Software Quality, measuring it, and communicating about it, so the team understands the impact as much as we do. We’ll also pick up things along the way while we’re delivering projects or studying that the rest of the team doesn’t know is even a possibility. We need to bring them to light.

That’s a lot of “extra” responsibilities. But to own our careers and escape the build trap, we need to do this. The best part about doing this is that work becomes way more collaborative and satisfying. We build trust in the team. If you’re an engineer, I hope this helps you take more ownership. If you’re not, I hope this convinces you to include engineers in your Strategy. If I save one wasted quarter with useless features or products with this text, it’s done its work. Let me know if that was the case for you. 🤙🏾