Better ways of working: confident product delivery

There’s an age-old question in the product delivery space: How can we build and release products with high confidence?

Through digitalization and globalization in an ever-expanding human population, the pace of doing business has never been faster and more uncertain. However, the core of good product delivery has not changed. Quality product delivery means solving customer problems in order to deliver a world-class experience at the right time and place.

Traditional organizations have structured product delivery around pools of specialist teams (UX, data teams, security, localization) where each function optimizes its work, but does not look at the whole process end-to-end. This leads to unforeseen delays and in large enterprises it can be hard to follow all of the established compliance rules in order to release something to customers faster than startups can do it. This is especially painful when at the eleventh hour, some new compliance rules are “discovered” and the decision is made to follow them. Typically, this happens in organizations where product teams are not the real owners of products, rather strategic and tactical ownership sits higher up in management and in the cracks of matrix organizations. Such teams are in constant flux based on changing stakeholder priorities and needs.

But, thanks to Emergn’s work-based education approach, based on the principles of Value, Flow and Quality (VFQ), our teams are equipped with best practices for improving product engineering and remaining competitive in today’s market.

Let’s cover a few of the main challenges and the best practices we use here at Emergn to overcome them.

Challenge #1 – Lack of context

One of the challenges when developing complex systems is the lack of common context. Without context, different teams can struggle to reach a common goal. However, by asking a few simple questions early on, you can help level-set expectations across the organization.

When building a product, understanding the customer concern helps everyone involved extend their understanding of not just “what we need to do” but move towards more important questions like:

  1. What is the real pain point for customers?
  2. What are the opportunities to address this pain point?
  3. How can we build a product to solve the customer pain point?
  4. What can be delivered to market faster?

The VFQ approach encourages feedback cycles as it helps people to validate what they are building and assess if everything is on track. And for products, the feedback that truly matters is whether customers are willing to invest their time and/or money—depending on the business model—in the product.

Challenge #2 – Why product releases matter

Deciding when to release a product can be difficult to navigate – especially if you’re new to the product delivery space. It can feel like you may not be releasing products frequently enough, or that you’re missing potential market opportunities. 

You may also be suffering from an increase in scope because that “one final touch” gets added several times, delaying the release. In this case, think about how you can break the work down and deliver something of value to the customer sooner with clear acceptance criteria and a definition of what ‘done’ truly means. In our experience, having proper measures in place will provide the data needed to make appropriate improvements.

Anything that is not in the hands of the customer is not generating learnings and data from real customer interactions. Any feature or capability added to a product must serve a measurable purpose. Depending on the product lifecycle, we care about different things. Initially, that might be the speed of learning and discovering more about users, later it could be optimizations and increasing the product operational margins.

The gut feeling you have is useful, but you can’t simply rely on it to evaluate your release frequency. The VFQ approach encourages us to introduce measures to understand what the release frequency is like today and find opportunities to make improvements. It is also important to understand what kind of work is getting done and how it affects products’ leading metrics.

Challenge #3 – Making changes on the fly

Most of you are familiar with situations where requirements and priorities change on the fly. It triggers pressure to deliver on the new goal and is often the main reason that projects are derailed. It doesn’t feel fair, right? However, VFQ supports the agile notion, where changing requirements are welcomed, even late in development. I fully support this, as it’s the way business works in a volatile environment – to have a successful product, you must be willing to change direction.

The VFQ approach offers several ways to solve this challenge. The first is to schedule feedback sessions specifically to identify what the real problem is. By doing this quickly, you can ensure all stakeholders are on the same page. Once the problem has been clearly defined, you can start experimenting. It’s also important to plan for these unexpected occurrences. For example – include extra time for unexpected changes in the sprint planning. Or even better – instead of Scrum, apply a different agile framework such as Kanban, where you can define clear policies by stating what the limit of unexpected but important work is.

The VFQ approach states that teams should have high autonomy and an open mindset – so they are able to make such experiments and solve the problems by themselves. The final outcome is that all sides are happy!

Teams often know something isn’t quite right but can’t always pinpoint where the biggest challenge is in the delivery process. Following VFQ principles, teams can visualize what the biggest constraints are in the flow and help drive deliberate improvements in your teams’ ways of working to drive better results. This also helps to identify areas to focus on for macro-level improvements, like reimagining the quality assurance process, which you can learn about in our next blog post.