Top 6 Factors Behind a Synergetic Product Development Team

by Team Userlane

5 years ago ・ 12 min.

Finally! Your new product upgrade goes live. It felt like almost everyone at your company participated in bringing the idea from conception to reality. Engineers and product people celebrate and feel confident that this new update is going to solve every issue your customers have encountered with your product. 

But … weeks go by. You check your KPI dashboards. There’s low adoption from your users. Support tickets are still being filed. A few more weeks. The same results. 

Where did you go wrong? You collaborated with your team to get everything done on time, you tested and tested, and you also made sure that you communicated everything to your users through every possible channel: In-app feature announcements, social media, email, everywhere! The company is confused and wants to understand more about the situation. Both engineers and the product team are feeling defeated. Your launch was planned perfectly. What happened?

If you work in product management or engineering, this scenario might sound all too familiar. 

Product and engineering work hand in hand, but when the responsibilities overlap and a variety of factors are constantly at play, it’s hard to avoid friction between the two. 

In this post, I will talk about the partnership between product and engineering and how you can establish a smoother alignment and work together as one symbiotic unit. 

Image source

Product vs. Engineering: The Core of Product Development

In a SaaS utopia, SaaS product managers and engineers would work flawlessly and the collaboration would flow in effortless harmony. But in reality, this relationship is a bit more complicated. 

Yes, sometimes there may be disagreements or a difference of opinion here and there. Perhaps specs weren’t perfectly defined or there were requirements that were only half-baked. 

But truth be told, a little “healthy tension” never hurt anybody. In fact, this tension is partially responsible for driving momentum behind new feature releases and completing product updates.  

Think of the World Cup or the Olympics. If there wasn’t pressure for the athletes to perform, would it even be interesting to watch?

But if it’s just two separate teams working towards the same strategic goal, why is it so difficult to align the two? What is the source of the common miscommunications? Why is there friction? And finally, what can you do to improve this collaboration?

Agile 

If you ask someone working in SaaS about what their collaboration looks like, they would probably describe it in one word: Agile

This shouldn’t come as news to anyone who works closely with engineers. A study from CA Technologies states, “Around three-quarters of executives in the survey said that  [agile practices] can play a crucial role in delivering the right products and services, accelerating decision-making and speed to market, while also improving the customer experience and staying ahead of the competition.”

But what do people mean when they say agile?  

Agile project management means that you have an iterative and incremental approach to how you deliver the requirements in the product life cycle. Agile, in theory, promotes trust, flexibility, and, above all, collaboration. The most common trait you will see in agile is working in sprints or short recurring periods of time. Meaning they could be in other small teams that work closely together. 

Although many businesses claim to operate with agile practices, the majority of them still fail to implement agile throughout their entire organization. 

In the same report, only “44 percent of companies report that agile practices are widely used within the development team, and 41 percent say the same thing for IT operations”, leaving a wide gap between acknowledgment and actual implementation. 

Agile/SCRUM

You can’t talk about agile practices without talking about SCRUM. Both teams are working in SCRUM, which is an agile project management framework that is commonly used to manage a project.   

SCRUM relies on cross-functional teams, which is why it is widely utilized by product and engineering. 

Let’s take a look at what both teams are responsible for and how SCRUM would apply:  

Product Management

Product focuses on the product, of course. But not only just on the functionalities and features – they focus on the WHY behind this too. 

They are taking the ideas and bringing them from conception to reality through thorough in-depth research that focuses on the user experience, creates a product roadmap, and turns it into specs for the engineers. 

They are big-dreamers, they strategize and use design thinking to create sophisticated UI/UX flows for customer personas, and they plan what integrations would work best. At the same time, they are managing expectations from both the customer and stakeholders. 

Engineering 

Engineering is the technical team of developers creating code and informing the product team of any potential backend issues that would affect the front-end functionality of the product. 

Engineers are focused more on the HOW and the WHAT. Product hands over the specs to the engineering team so that they have all of the information to start developing.

Most Common Issues between PM and Engineering affecting Product Development 

The product development team is there to develop, support, and create the overall product vision. But investing in such a project without properly aligning first is destined to encounter some problems somewhere down the road. Here are the most common issues you will find between product and engineering: 

Prioritizing –  Product managers have to consider many aspects before handing over specs to the engineers. There are budget constraints, backlog, stakeholder influence, bugs, and of course, product/feature prioritization. Each decision the product management team makes here has a direct impact on the engineering team. The product team needs to develop the right product prioritization framework that works for the business in order to operate properly.

Speed – Speed in software development is always a hot topic in SaaS, but it usually conflicts with quality of production and is a usual suspect for when things go awry. Speed also varies from engineer to engineer based on skill level and experience. Time pressure will always be a factor in the software industry, but it doesn’t necessarily have to be the only variable determining the outcome of the product development process. 

Silos – In many instances, you see product and engineering working in separate but parallel worlds. There is a sense of separation between the two teams like there is a wall between the two. Most likely, there is a lack of communication and both teams just try to execute blindly without fully understanding the reasoning by the request. 

Product Development Team: How to Work Towards Better Alignment

At its core, working towards better alignment all comes down to proper planning and communication. It sounds simple, doesn’t it? Only two fundamental things to focus on, yet so difficult to execute. 

But as with all things in life, planning and communication need practice and the ability of team members to learn from previous setbacks and mistakes. 

And when it comes to SaaS, the focus here doesn’t begin with what product or engineer want but rather with what the user needs. Here are some tips to get you started on improving your team collaboration efforts!

Start with Explaining Why

Everyone needs a purpose, right? Doing anything without a purpose is simply demotivating. That’s why each team lead needs to explain WHY you are working on/ implementing something. Having no purpose can be pretty disastrous. It just leads to time wastage, miscommunication, and a lack of passion and desire to achieve anything for both the company and customer. 

The why and the purpose form the foundation of building that team alignment. And just as having no purpose is disastrous, so too is having extremely differing purposes and whys. It’s all about having a clear vision and a clear strategy. Set objectives. KPIs. OKRs. How can you measure outcomes and success if you don’t know what you’re measuring and why you’re measuring it? Individuals need to work towards a goal, an overall purpose, and be motivated to achieve. 

Whenever you give an instruction, such as “we need to meet the deadline”, make sure you always give the WHY first. Just explaining why can do wonders for motivation and coming up with even better ideas and quicker solutions. Form a strong team identity by making the mission clear and uniting everyone around a clearly-defined (and explainable!) goal.

Teamwork Makes The Dreamwork (So Does Keeping Calm)

There’s no I in team – how many times have you heard that cliché?! But you’ve got to leverage the individual skills of each team member because every person will add value in some way (think of your hard and soft skills here – each person will have their own strengths in specific hard and soft skills). 

Also, if you’re a team lead, don’t be afraid to share responsibilities and then hold your team members accountable. Respect each other, yes, but be strict when it comes to accountability. 

Then, always try as best you can to maintain an atmosphere of calm. Human psychology and behavior is complex, of course, and every individual on the team will react differently to different situations. However, everyone is affected by stress and a tense atmosphere, and there is a reason why psychologists advocate for reducing stress levels in order to think rationally and make better decisions. By maintaining an atmosphere of calm and “we have things under control”, teams will be much better equipped to deal with the pressures of new product releases etc.

And importantly, don’t have the proverbial blinkers on where one team takes preference over another. The product manager and engineering manager need to take ownership of their respective teams, but not at the expense of the other team. Don’t protect your territories and build silos. It’s all about COLLABORATION, or for an even better word, SYMBIOSIS! Here’s a good quote from James Stanier, writing for the The Engineering Manager: 

…a feature team without a good product owner is stunted in their ability to do their most impactful work for users, and a product owner without a good engineering team is unable to deliver their vision.

Quality Assurance and Testing is Everyone’s Responsibility 

Quality assurance and testing don’t just belong to one team. It’s a joint effort. And testing goes hand in hand with learning. It is up to both teams to learn why something did or didn’t work, and then come together to discuss this. 

Essentially, everyone on the product and engineering team is responsible for the product and assuring its quality in some way – whether big or small. The final product is a sum of all its parts, and if there are certain individuals who aren’t putting in effort or quality work, this will, naturally, cause problems and impact the quality of the product.

Ownership and Partnership 

Once again, this comes down to collaboration. Define which team builds what – and focus on the WHY. Keep in mind that although each team will be owning a certain project or task, the product and engineering teams are essentially like a brain: Yes, there are two individual teams (just like the brain is divided into two hemispheres), but the two hemispheres (i.e. teams) work together – you don’t just use one half of your brain now do you?! 

Although the product owner owns the strategy, ideas, and backlog for the product team and engineering owns the implementation, this does not mean that the product team micromanages the engineering team or vice versa. It means working together: Feedback loops, regular check-ins, meetings, open communication, and being realistic. 

And keep in mind that if you’re on the product team, the engineers’ feedback and concerns must always be top priority! Answer their questions immediately, help them test something when they think it’s ready, motivate them when it comes to meeting those scary deadlines, praise them where its due, and accept and work through failures together. 

If you think about it, everyone actually “owns” the product in some way because they’re responsible for developing a certain aspect of it. Rather look at ownership as a partnership because, without collaborative effort, your SaaS product will never be the best it can actually be. 

Engineers need to be a partner in the product process, just as product needs to be a partner in the engineering one. See ownership, as well as leadership, as something that is shared. This is something that popular work management platform Asana focuses on really well. At their company, they make it their mission to “explicitly share leadership between product managers, engineers, and designers.”

You Are All the Customer Advocate

What makes a good product and engineering team in a SaaS company? Well, a lot of the time, it comes down to finding a balance between team members, what they envision an effective team should be, and what customers actually want and need. Everyone on both teams needs to be a customer advocate because this means that you will all be working towards what the customer wants. And when you’re all working towards a common goal, what do you have? That’s right – alignment!

The best way to be the customer advocate is to focus on the user need you’re trying to solve for. This way, you can achieve the desired outcomes with the least amount of added complexity. That’s win-win-win for everyone.

Ask yourself (and the team):

• What’s the user need and is solving it worthwhile?
• How can we validate that this is the right user need to solve for?
• What is the ratio between complexity vs. value?
• What is our hypothesis about this feature once released?
• What are the support costs?

And if you are already applying the Kano Model in your UX/Design/Product strategy, you are one step closer to being the true customer advocate and achieving customer satisfaction.  

Image source

In a SaaS company, your goal is to deliver user value, and it’s the responsibility of all teams involved to plan and consider what value and benefits you’ll deliver to your users when releases will take place, and what risks are involved. Don’t assume that it’s the responsibility of the product manager, for example, to think about product risk – everyone is involved in the planning process, and this is the only way to deliver true value to your users. 

Having Clear Roadmaps

Have clear product and technology roadmaps. We emphasize the product roadmap a lot in our blog posts, but it’s also crucial to have a clearly defined technology roadmap that everyone can understand. 

Prem Sundaram, a leading product development consultant, used the Technology Product Canvas concept to address the alignment of product and tech teams.

In Prem’s words,

The Technology Product Canvas forces your team to state and visualize the product roadmap goals, technology roadmap goals, and discuss each product-technology stage of the roadmap explicitly. This exercise ensures the teams are in-sync and everyone can leave the room with clear expectations and direction.

Prem recommends that the product owner initiates the TPC discussion only after the product vision has been defined and both the user story mapping process and initial product release roadmap have been completed. From here, product and tech teams can align by having a detailed, technical discussion on HOW the product will be built. 

To begin the TPC discussion, everyone needs to know WHY they’re there and define EXACTLY what it is they want to achieve. Define success metrics. Complete the product vision and evaluate what the product development priorities are. In the images below, you can create goals for each section by working together to create these goals – it’s a collaborative process. 

From here, define the engineering team’s vision and then seek to align the tech plans with the product goals. After this, you can assess risks and resources. What risks could arise when developing the product and what resources will you need to build this feature etc. You can create your canvas in Miro, for example, or use this example to get you started!

Product Development Team = One Unit, Not Two Teams

Innovative product ideas can come from anywhere, but you need an experienced product development team to turn the ideas into tangible results. 

The bottom line is: If you want a product that meets customer expectations, this collaboration needs to work. Because you can’t have a development team with a good product owner who cannot understand the needs of the user, and you can’t have a product owner with an engineering team that can’t deliver. 

Both teams aren’t there to serve each other, they are there to make the customer experience one that is worth experiencing.  

No engineering or product team is perfect, but if you both want to streamline your collaborative efforts, take a step back and invite both teams to discuss ideas and technical approaches openly, critically, and honestly. You will find that the short term results (positive outlook, more clarity on the project) will bring your team closer to your desired outcome a lot quicker. 

A successful product isn’t just based on product and engineering – it also comes down to how well you onboard your customers! A great onboarding experience will lead to product adoption. Watch the recording of our exciting webinar with SaaS email strategist, Stephanie Knapp, on how you can optimize your onboarding email strategy and increase those all-important conversions!

Check out our latest webinars