A few weeks ago, we held our first Product’ive Breakfast, a roundtable event for Tech professionals to come and discuss all things Product. Hosted at our offices, with Carlos Silva – VP of Product at Jinn, we explored trends in the Industry, focussing on the relationship between product priorities and business goals. There seemed to be a common theme – these two things should be aligned, but more often than not, they simply don’t match up.
We shared a general agreement that business objectives and products priorities should be one and the same. However there were several examples where this was not the case in practice. Problems mentioned included: mis-alignment on KPI's, lack of KPI's, using KPI's to drive agendas, lack of communication, unrealistic expectations regarding timelines, difficulty aligning long term vision with short term needs.
Overall, we found the morning to be a collaborative and valuable means for Product Managers to pick apart their concerns with likeminded individuals. It was great to see everyone participating and we’re excited about planning our next Product’ive Breakfast.
The discussion focussed around three main topics, and we’ve explored them below. The following is taken from a transcript of the event, which has been edited for length and clarity.
Conflicting KPIs: The Opinions of the Business
Conflict in the product world comes from different teams chasing their own KPIs. A lack of collective prioritisation means that each department can become focussed on a variety of business outcomes.
We looked at the idea of Prospecting versus Mining. Product people are natural prospectors, always looking to add value to a product, delivering the best possible experience to customers. Mining is the “making money” part, finding a good product and just getting it out to the market. At this stage, business and cultural challenges occur, as product innovation is no longer a priority. This shift can often occur as a business grows, and KPI’s move to being solely commercial.
Unrealistic expectations from senior stakeholders results in a clash between a Product Team and the wider business. We discovered that ideas can be dropped in seemingly without context, or a real understanding of how a product is built. This leads to a Product Manager identity crisis, weighing up long term creative value against business goals, as expected by stakeholders.
There’s a real risk of delivering a substandard product, if teams are trying to nail KPI’s that are only aimed at generating revenue. KPI’s can erode the quality of a product, especially if the main goal is to just get something out the door. Instead, should teams be paying more attention to customer experience and long term value? It’s clear that it’s far more valuable to compare the commercial benefits with those of the user. KPI’s have a habit of existing in isolation, so teams need to know which direction they are steering the business in.
Responsibilities: Product, Engineering and the Business
This is the what, how and why respectively.
We discussed a great metaphor during our event. Think of Engineers as chefs. Their business is throwing a huge party and needs to feed 200 people. The Engineers are of Michelin star standard, but they’re only provided with microwaves and a tin opener. They have to build their own ovens. In order to prepare the best food, they have to create their own tools (microservices, architecture, etc.) The business, however, only cares about getting people fed.
This example really sums up the sentiments many of the Product Managers shared about how businesses handle their priorities.
Product is very much a part of the delivery mechanism. Spending time with developers is incredibly valuable, particularly as often the Product team sits closer to the business than engineers (even though this shouldn’t be the case).
Promising something that can’t be delivered will lead to a breakdown in trust between teams. It’s no use just plucking numbers out of the air, simply to show momentum. Instead, challenge deadlines and work towards a common business goals.
Product teams must study the market, study their customers and figure out what needs to be built. It’s the engineers job to work out how to do it and when. Understanding the difference is fundamental to business success – don’t confuse what with how. Maintain a united front in building value, not just a “thing”.
Our panel agreed that Product teams could use concepts to compare the absolute minimum requirements and the perfect finished product. How much is the business looking to prioritise time and resources over the quality of a product? Establishing this means that each department can understand how their particular responsibility corresponds to the overall success of the product.
It’s paramount that teams have visibility over where each responsibility lies. Throwing an idea “over the wall” to somewhere else in the business, and wondering what’s happened to it in six months’ time isn’t going to get things moving. There’s no point in simply delivering what you need to deliver, if it’s not adding value. Ask your customers, run tests and work out what could be at stake if the first version is a failure when it goes live.
Co-Create: Managing Expectations
Bring people together. Those involved with creation and delivery of a product should be present at the ideation phase. Define the problem and explore solutions as early as possible, with all teams. Setting expectations at this point that are aligned across everyone will allow you to define success and instil that throughout the process. Focus on the problem rather than the preconceived solutions.
Strive to involve each team as closely as possible. Everyone should know what a healthy product looks like and this is much easier if the developers have been taken through the product usability, allowing them to be part of the analysis and target gathering. If the customer is not being represented, you’ll end up with the wrong product and expectations will not be met.
No one wants to be the person saying no. Using prototypes is a great way to show what is achievable. In explaining what can be done, and what is possible in a given amount of time, a clear channel of communication is created between Product and the rest of the business.
We discussed if there’s a difference between responsibility and who actually executes each step. Responsibility for a product should live with everyone involved, whether that be Tech, Product or the wider business. There must be a mutual interest in the product working.
What problem are you solving for your customer? Involve engineers so that they fully understand why they’re doing something. People will be far more passionate if they’re bought in. Add an emotional connection, and this will in turn add meaning to the work being done.
It’s the Product Managers job to motivate engineers. The Engineers are craftsmen, working on scalability, delivery and fixing bugs. As a Product Manager, working alongside tech teams will allow the Engineers to trade off little problems for big picture thinking, making the pipeline and product bulletproof.
Product Managers can default to delivery, obsessing about design details with developers, but forgetting about measurements and investigating which features to keep or remove. They have the ability to add real value - Research, ideas, scoping and shaping a Product with engineers. Their job is to ignite people, working with teams and understanding how to tackle each obstacle. The more motivated everyone involved is, the more likely it is that goals will be achieved.
