How we deliver Unleash

Being a product company, how we deliver our product is essential to our success. Everyone plays a role in delivering Unleash, whether it is as a developer writing code, pre- and post-sales technical support, sales & marketing as well as our management. Everyone plays a role to ensure Unleash is developed to be the preferred feature management platform for the developers out there.

 

The first version of Unleash was open-sourced in January  2015. The initial motivation for building Unleash was to enable the team where our founder, Ivar Østhus, was working at the time, to push code to production as a continuous stream of small changes. As most agile teams recognize, there are multiple reasons why pushing code to production is delayed. It may not be fully implemented, it may not be properly tested, and the feature may not be considered “complete enough” by the Product owner. Delaying pushing the code to production delays the feedback cycle for the development team. Having the developer pipeline fully automated at the time, being able to enable and disable a new feature without the need to re-deploy to production seemed to be the perfect answer. The idea behind Unleash was born.

The product direction

The vision of Unleash is to remove the hurdles and stress developers experience today when releasing new software. Software developers want the freedom to create and getting feedback from their users is more important than all the bureaucracy included in release management today. This is why Unleash exists. We have further defined four key areas where we want to move Unleash forward. These are 

• Developer Experience
• Operational excellence
• Enterprise security and compliance
• From feature configuration to purpose-driven feature management 

The strategic themes are set to provide a clear direction where we believe Unleash shall evolve, without being too specific on the features to be delivered. This is important. It provides a framework for discussing and prioritizing new features for Unleash. This allows product organization boundaries and a clear direction, at the same time full freedom to identify and create features that benefits the users of Unleash. All features are put into one of these 4 strategic themes. The product organization has full freedom to identify what features make the most sense in order to improve Unleash along with the strategic themes. 

 

What to deliver, when?

When a new feature is being considered, the pain the feature solves for the user of Unleash may or may not be very clear. We believe most software development teams will recognize that often a feature request comes from talking to customers or looking at a competitor’s product, and it may not always be obvious exactly what problem the feature needs to solve. In these situations, it is difficult to design the new feature – it is just too unclear. 

For these features, we have decided to follow a product innovation discovery process as illustrated above. This process is known as the “double diamond” and is intended to support the product team to get a much clearer understanding of the real pain we try to solve for our users. The methodology consists of two key phases

• Research or “design the right thing”
• Design or “design things right”

 

For the first phase, “design the right thing”, our product team is working with our users to understand what pain the feature is being designed to solve. The users may come from our open source community or from any of our customers. Here we are looking for users that really feel the pain we are trying to solve. In this phase, diving into input from pNPS and CSAT, collecting data, user interviews, high-level mockups and the like are being used, and it is guided by our Customer Experience team that is trained in these processes. When there is a clear problem statement, the actual design of the feature is started. Depending on the type of feature, the software developers may or may not write code in the first step (“design the right thing”) of the process. For example, a set of detailed mockups or a prototype can be enough to validate our problem understanding. It is important to highlight that the product team may understand that the problem statement was wrong and decide to move back to the first phase during implementation. Guided by a clear product vision and the strategic themes, we trust the product team to make this decision to make another iteration when needed. 

 

One observation we have made working with multiple software development teams over the past few years is the desire to implement what is considered a “complete” feature or process in the software. This may come from any stakeholder to the product, even the software developers themselves. Often this is referred to as “gold-plating” – making sure that any possible situation for the feature needs to be implemented before the feature is considered “done”. In the situations where we recognize that we are not sure exactly what is “good enough” to solve the real pain for the users, we mitigate “gold-plating” behavior by referring to the releases as “iteration 1 of the feature” or “iteration 2 of the feature” and so forth. We have found that using this naming convention (“iteration”), we clearly communicate to all stakeholders that what we now deliver, is one of the possibly many improvements. This is a simple way of managing the expectation that we may need to do more to this feature, at the same time there is less resistance to allowing real users to test what we consider the minimum viable product. It’s important to highlight that each iteration of a feature is considered production-ready and of high quality.

 

Cutting new features into smaller iterations also brings us into another key learning it is important to highlight. To us, agile or even DevOps doesn’t mean moving forward without a plan. Planning is still of importance to any agile process you may follow. The key takeaway is that planning is a continuous process, from a priority, activity, and order point of view. More important than anything, is to ensure that the feature is delivered to real users in order to gather feedback and new insights for the product team.

 

How to make it happen?

Most software organizations today either have implemented or intend to implement autonomous teams. While autonomy is great, it is also usually the case that multiple teams need to take part in delivering the software. Reasons may be many; some of the obvious is that the code in itself is too large to have one autonomous scrum to handle it end-to-end. Another common situation is that multiple competencies are required to deliver the software, all from sales and marketing, to customer success and support to the software development teams. One observation we have made working in multiple large software organizations is that handover between internal teams creates friction for the customer and the customer journey. The friction is particularly visible when the customer journey is spanning across internal reporting lines in the organization. This may be due to different focus, different competencies, different internal KPIs, and similar. Until now, we have not been able to successfully design an organization where this friction isn’t apparent. In order to mitigate this, we have decided to introduce a senior role into the organization responsible for the Customer Experience. Our Head of Customer Experience has the mandate to map our end-to-end customer journey to monitor and identify these friction points. When we know about them, it is easier to minimize their impact on the customer experience.  

 

To create a best-in-class product, allowing decisions to happen as close to the creation of the product as possible is something we consider as very important. In order to put our teams in the best possible position to make the best decision for Unleash, we have found that access to customer insight and data is important. This may be obvious to most, but this can’t be stressed enough. Some observations we have seen working with different product development teams, we have seen some characteristics, and anti-patterns, to be aware of. 

 

The first is the “Lead product manager”. This is often an experienced product manager or product owner that has full insight into what the customers’ needs are, and that dictates the design of the new features. There are situations where this may work, in the sense that the customers love the product. The first challenge with the “Lead product manager” is that there is little or no ownership of the product being developed. Our experience is that lack of real ownership leads to less engaged teams. Low engagement tends to lead to less performant teams. Further; the “Lead product manager” creates a high dependency on this one person. If not present – the team is likely to struggle. To mitigate this characteristic, our product management is focusing on facilitating learning through processes, as well as guiding the product team through the product vision and the strategic themes decided for Unleash.

 

Similar behavior is that key teams or individuals restrict access to the users. This may be done by sales or customer success teams that act as proxies between the product development teams. There may be many arguments why this is needed – access to information is usually common to all. In order to avoid this from happening, we are focused on all roles interacting with our customers. The interaction may happen in traditional sales or customer success calls. We have also established a Slack community open to all – to foster interaction between our team and all in the Unleash community. 

 

Delivering a best-in-class customer experience comes down to the people in the organization. Do we as a company trust and empower them to make the decisions for what makes Unleash the best possible product? Building such a company culture requires support from senior management. As founders and senior management, we are required to lead the way, trusting everyone in the company to take an active part in the decision-making of what and how to best deliver Unlseah.