Though we hate to admit it, most businesses operate within a system that treats product and engineering teams as separate entities. We have user-orientated mindsets working on defining the problems the business intends to solve and those who translate those goals to code on separate ends of the spectrum.

Not so long ago, engineering systems required tenfold the amount of hands-on implementation as they do today. Every nitty-gritty technological detail had to be hashed out before teams were able to execute. With the rise of open source software and the advancement of the field as a whole, we need to improve our approach to delivering software.

Instead of expecting well-defined acceptance criterion to be handed off, product-driven development requires engineering and product to work in tandem to not only vet requirements from a feasibility standpoint – but to suggest enhancements based on the engineer’s technical understanding to better serve the end user. PDD brings engineers in the loop to communicate early and often.

Similarly, PDD empowers our product team in every step of development. It is inherent to an organization’s success that members of the product team are also looped in to the development process – reducing the potential for bugs and miscommunications while improving the end product.

So, how do we get there?

Accept the fact that change is hard and organizations don’t change overnight; however, there are many tools / processes you can explore. To implement these changes, it doesn’t matter what team you are on – these changes rely on working together.

This organizational shift is not aimed at favoring one department over another. First and foremost, it is about delivering the best value to our users. We do that by:

  • Eliminating silos and collaborating on solutions from day one
  • Building joint MVPs to reduce delivery time while also ensuring scalability
  • Empowering product by shortening the feedback cycle
  • Improving developer experience to improve user experience
  • Implementing solutions effectively by working across teams

Shape your work holistically

Too often work is shaped in silos. When we scope out solutions only on the product or engineering team, we aren’t typically thinking of the impact on our counterparts – nor are we building the best solutions.

Cross-team impact is huge. It can easily spell the failure of an organization, let alone feature releases. I’ve seen and personally been a part of engineering teams scoping out breaking changes without product representation. The success rate these projects see when they aren’t communicating with the product team are dismal at best.

It is your duty to loop in your counterparts. Collaborate on minimizing negative impact on the other departments and create a plan for moving forward. When scoping out work for a recent breaking change, we collaborated with members of our product team to solution a way to communicate the change to our users and funnel them into a smooth upgrade process – something that wouldn’t have been considered without product’s involvement.

Often times engineers can be seen as nay-sayers, but when they are looped in early to product meetings they can be the most important people in the room. If we want to be a product-driven development organization, we must build joint MVPs.

Typically a minimum viable product is only considered on two dimensions – time to deliver and value perceived by the user. This is nearly the whole picture, but it’s missing a critical piece: a path forward. Scoping out MVPs together, engineering and product can deliver higher quality solution in less time with much quicker follow-up deliveries.

How can we expect our engineers to build truly scaleable solutions if we are only considering the technical nature of the MVP? In order to architect these deliverables correctly, they need exposure to the product teams thought process. What does the next release look like? How does the product roadmap look in terms of horizontal and vertical scale?

Including engineering in MVP discussions can change the game entirely. When product and engineering representatives work together, we can optimize the what and the how of our scope. Together, we can actually eliminate work by identifying commonalities from the product roadmap and generalizing our solution. By making our scope more efficient we are reducing the time to implement and get feedback from our users, but we are also giving the product team a boost as to what we are capable of doing in the future – perhaps adding capabilities and options that would have remained unseen if we hadn’t worked together.

Improve your tooling and processes

Nothing frustrates me more than dealing with inefficient workflows. If I were a designer and didn’t have a system in place to push design changes to the product, I probably wouldn’t push hard for those changes to take place.

Our goal should be to reduce friction between identifying the work that needs to be done and delivering the outcomes. This can take on many shapes and forms and the most important thing to note is that this is not a standard one-size-fits-all solution.

The best way to continuously address tooling/process improvements is to revisit the problems you’re having on a consistent basis. No matter if you’re working in X week sprints or traditional waterfall, you should be scheduling time to talk about your process and how you can smooth workflows between your product and engineering teams.

Every 6 weeks, our team spends an entire week experimenting with potential solutions to these types of issues. Whether it’s using new languages, tools, or process adjustments, discussing these changes across our departments has lead to incredibly effective change. We are currently discussing how we can improve our code linting to help developers catch potential bugs while programming and plan on refining the work to put that in place in the coming weeks.

When you put your product and engineering teams together to address their frustrations, you empower them to make the changes that will transform your organization to perform at its best.

Continuous integration and delivery

The most dangerous solutions are the ones that gather dust waiting for release. When we aren’t constantly vetting our changes from a technical / integration standpoint as well as a product acceptance level, our solution will decay. Even as a team who has fairly robust rolling releases, we still are working to improve this process – we’ve seen features fail to get the green light on releasing to production because we didn’t involve product in the development process.

Depending on your organization, there are a few methods to shorten this feedback loop. For the most part, B2C companies can simply ship an internal application and give their product team access to give feedback on the work that has made it through development.

CI / CD might be a little more difficult when you’re a B2B, but it’s just as important. One method we’ve found to maintain a great release cycle is by treating our organization as a fake client. This client gets all the goodies and bleeding edge features, but we still have a rollout process for them. Everything goes from internal development, to acceptance testing, and – only when product has signed off – production.

Enacting this change has a few side-effects that aren’t typically thought of during implementation. While we expected our product team to feel empowered and be able to rapidly course correct, our engineering team was ecstatic. Seeing code get shipped in an instant instead of months boosted our engineers happiness, and I don’t have to write a book on employee moral correlating to better products because there are already hundreds out there.

Cross-functional pair programming

What if I told you that your organization’s pair programming practices were only 50% effective? Traditional pair programming is an excellent tool that’s typically only used within engineering, but what if we brought in our Product Owners or our UI / UX Designers?

There are many ways to organize these sessions, and I encourage you to find use cases for more. On my team, there are two general ways we do cross-functional pair programming: functionality and design.

When implementing some functional change to the product, having a pairing session with your PO / PM is a great tool to seek clarity on requirements. Think of all the times a feature has gone to production and someone has said “that’s not the way that was supposed to work”. While a solution may be passing all the acceptance criteria that was written, we must accept that we cannot document everything in our minds – it is no shortcoming of our product team. By bringing them into the development process we can tease out these undocumented / unclear requirements before we are shipping code.

The same situation can be applied to our user experience and interface work. When we bring engineers and designers together for a similar session, we can start a dialogue about what are the compromises – or improvements – we can make to the implementation of the design. This will not only make everyone involved happier with the outcome, but will also improve the quality and development speed of your solution.

Where do we start?

At the beginning of this piece I mentioned that organizational change is hard, and accepting that is the first step to doing anything about it. You and your colleagues must buy in to the fact that departmental silos grow like grass, and it is a constant process of addressing these problems by identifying how you can solve them. Your next step is up to your team, what do they think is the most valuable improvement your organization can make in the shortest amount of time?

We’d love to hear any of your stories and successes with bridging the gap between engineering and product teams. Who knows, you might just spark change in others.