Planview Blog

Your path to business agility

Project to Product Shift, Value Stream Management

How to drive customer obsessed Product Development

Published By Tasktop Blogger
How to drive customer obsessed Product Development

At Tasktop our Product, Engineering and UX teams operate under a single umbrella called ‘Product Development’ to make all our value streams “customer-obsessed”. Our teams do not work in silos or a single project, rather they are focused on optimizing the value stream for a single product – such as Tasktop Integration Hub – to continuously delight end users.

In my past career as a Software Engineer at a giant Fintech company, I seldom got the chance to talk with the Product Manager of my team. We worked with technical documentation and assumed that my work contributed to business objectives in some way.

My Engineering Manager was my only point of contact and I could only imagine what the Product Manager looked like (as he was located on the other side of the world). This wasn’t the best way to work but I guess that’s just how big companies operate. The execution team does what the strategic team tells them to do and no one knows what happens after that.

Due to this experience, one of the biggest objectives of my career post-MBA was to be a Product Manager (PM) who worked with the Engineers regularly to decide on strategies based on the product capabilities, as well as the ideas and velocity of the team. Tasktop shares this mindset, making us a perfect fit. 

A healthy relationship between the PM and Engineering is critical to building customer-centric products. A shared responsibility to provide value to the customers is essential for the shared mission of being customer-obsessed. Here are three key ways you can begin to improve the collaboration between the two departments:

1. Prod-Eng collaboration during Discovery phase 

The product development process is broken into three phases: Discovery, Execution & Rollout.

  • Discovery is the work that the product manager undertakes to define the Epic scope and Feature set before bringing it to development
  • Execution is the work that happens once the development team starts working on an Epic from design to development & testing
  • Rollout is the process of deploying the feature/product to the customer  

At my previous company, the PM of my team tossed over the feature vision along with some UX materials during the Execution stage of the release. The problem with this approach is that the Engineers must figure out a solution to fit the feature and the UX materials provided – both of which were envisioned without Engineering inputs. Consequently, the solution implemented will not be the most optimal way to achieve customer value and happiness. 

Prioritization is one of the most important tasks for a PM. Involving Engineers in the Discovery stage results in better quality output and also exposes technical risks sooner, allowing better scoping and de-scoping. With this practice, the PM can also ensure that they don’t sign up for a deadline without buy-in from Engineering.

As easy as it seems, it really is not! Constant communication and explanation to understand why a certain feature/part of the feature is more important than another feature are crucial. Knowing your customers and empathizing on user pain points is absolutely critical. Tasktop has made the right cultural and structural shifts to be able to respond and meet customer needs faster.

 2. Clarity of responsibilities and autonomy to take decisions

PMs own problems and Engineers own solutions. Naturally, there is an overlap between these responsibilities that can result in loads of confusion and the bumping of heads. Neither a PM can vouch for how the code base should function, nor an Engineer can decide whether a feature is important for a customer. The simple reason being that neither of the parties can back up their reasoning with the right data. 

The mindset of a Product person is to prioritize and build features that bring monetary gains to the company either in terms of sales, renewals or market positioning. Trade-off analysis of the short-term vs. long-term gains is always on the mind of a Product person. On the other hand, the mindset of an Engineer is to design the most optimal solution for the problem in hand without incurring much risk (security, scalability, extensibility) or technical debt for the future. With clarity in roles and a collaborative approach, the leadership of responsibilities can be shared.

At Tasktop, every individual has the autonomy to make decisions. If the person or the team feels that processes or meetings are unnecessary and does not deliver value, the concern is raised, and the inefficiencies are cut down. Tasktop truly believes in “Less is more”.

 3. Shared credit and downfall

Sometimes PMs or customer-facing entities can end up taking credit for the efforts of the whole team. This is mostly because they are the ones presenting data to the executives, leading meetings, or announcing results. A product would not exist if it weren’t for the Engineers who build it. Having shared leadership in the Product, Engineering and QA teams to ensure high-quality products is the key to sharing credit (and accountability for when things don’t work out).

The biggest challenge of any growing company is to accommodate the four flow items: Features, Defects, Tech debt and Risks with limited human and monetary resources. Being customer-obsessed and making the right trade-offs to accommodate quick wins to tackle the above flow items becomes absolutely essential. 

What I’ve learned so far is that shared leadership, inclusive decision-making, mutual respect and helping each other succeed are the key ingredients in making a great Product Development team that continues to learn and grow.

Related Posts

Written by Tasktop Blogger