Recently, I came across a pictorial that showed all the products in the DevOps market and the sheer number was mind boggling. As the head of products at CloudBees, I am often asked about recipes to build standout products in such markets and I will share my thoughts here. I will speak in the context of the DevOps space but the lessons should apply elsewhere.

Challenges

A challenge in this space is that tools have been built by the tool users themselves or in other terms “experts have built for experts”. DevOps has been a ground up movement, tools are born because someone scratched their own itch. That is wonderful - the market space is validated! However, the early movement has become a democracy now - everyone is doing it. This implies that novices expect to come in and be productive but the tools aren’t suited for them. This is an opportunity to differentiate! A corollary of the above problem is that these tools have been around for dozen or more years and just like the roots of a tree have spread across the entire organisation and integrate with every conceivable tool in there. This is good news for your product from an adoption perspective but it literally means that you have to change the tires of a running car if you want to rethink your product. Me-too implementations can rethink the experience but usually end up as implementing toy use cases because it will take them a generation to catch-up and build for enterprise tools. This is an advantage for existing tools and an opportunity to differentiate!

Build Lovable Products

Standing out from other product requires building products that are clearly differentiated. There are a number of product levers that can be played around with to build this differentiation. Levers like ease of use, targeted use cases, better branding, lower cost. I will focus on the product because if the product isn’t right - fixing other things is like putting lipstick on the pig.

What’s your organising principle?

An organising product principle is the guiding light-house that aligns the entire organisation. For example, at CloudBees, ours is “Build a lovable product experience”. We constantly ask this of ourselves and use it to make tradeoffs in hard situations. This principle is highly energising and motivating - who doesn’t want to build something kick-ass and the principle sparks of very interesting and deep discussions in the company

What’s your organising principle? If you cannot articulate it - start here first.

Who are you solving the problem for?

You always have to remember that there is human on the other side who is going to use the product. Too often, enterprise products solve for all possible personas with the intention to make everyone happy. This results in user experience that isn’t targeted enough and consequently lovable enough or in other words clear-as-mud :-). Too often, I see that product teams forget about the persona and it shows in the product. At CloudBees, everyone from the exec team, marketing, sales and ofcourse product management knows the names of these personas, their motivations and even their looks. We not only know them, but target product requirements for that persona. We trade-off decisions based on the persona. It isn’t uncommon to hear statements like “Ada would never use this, this feature is for Simon and we aren’t focussed on Simon in this release”.

So, know the persona and make it as real as possible for a differentiated product.

Who is your user? Where does she sit in the organisation that you are selling to?

Who is your buyer? What do they do after work?

What are the right problems?

Once you know the persona, understanding the key problems is crucial. Building a good body of problems (at CloudBees we call it problem statements) is a matter of interviewing the target persona - rinse and repeat. The lean startup movement is exclusively focused on finding the right problems and I encourage you to read it.

How often does your user have the problem that you are solving for?

Rethink UX: Build a lovable experience

Simplify - don’t solve for corner cases. Solve the 80% really well and provide an escape hatch for the remaining 20%. Most devops product want to solve 100% of use cases 100% of the time. This leads to really complex products that hurt the novices coming in. Think how can you reduce the surface area so that people are not taking customers into a dark alley. Reduce the decision points that customers make. More decisions equals paralysis and leads to a frustrating experience.

As a side note: In the DevOps world, products cannot ignore the last 20% because this is where advanced use cases are solved. The key is to provide extensibility points so that customers can scratch their own itch. Fundamentally, this implies architecting the product so that it is extensible and implies factoring this architecture choice early in the vision of the product. Make a product extensible isn’t something that can be tacked on. If you are evaluating a product in the DevOps world, ensure that it is extensible.

Simplification becomes easy once you have the persona and the right problem statements because you can ask the right questions. Are you adding more value by allowing the persona to do more or are you simplifying a persona’s life by reducing the steps in the process that the persona goes through every day.

I strongly advocate for a market validation and research phase that happens prior to execution. This phase is usually for small, medium and large initiatives and not for a bug fix for example. Build mockups, prototypes and iterate. Iterate with design, iterate with engineering, iterate with support, iterate with sales and most importantly iterate with customers. This before any substantial piece of code is written. By the time a new feature set lands at engineering, it has to be vetted and certifiably lovable. Having an engaged customer advisory boards that have a good representation of your target personas is a compelling tool in a company’s tool set. Note: I am not advocating waterfall or agile - this is somewhere in the middle more towards agile.

Build a lovable team

A lovable product isn’t going to be delivered if the right team isn’t in the picture. The team should be a triumvirate of product, design and engineering. The roles should be clearly defined for the triumvirate. Invest in design, product management and engineering meaningfully. Too often, this part of the organisation is running at capacity keeping the fires down and then executives wonder why good products aren’t being delivered.

Product Management

The product professional owns the persona and the problems. She knows what needs to be solved for and has an idea how that should be solved but should not go about designing the solution. A product manager’s job should then ensure that engineering and design “get” the problem, closely work on building the right solution and validating the right solution. A product manager mocking something on paper and throwing it to engineering is perhaps the worst thing that you can do to build differentiated products.

Design

Design takes the problem and builds the solution and its user experience. The role of the product manager is to provide the right customer context so that the designer can design the right solution. Design should be empowered to stand up to engineering, product management and should own the user experience.

Engineering

Engineering comes in and keeps designers and product managers real. They help them understand the costs of the choices being made and then build them. By the time, the product feature is in execution, engineering should know the customer, the problem and design intimately.

Finally, provide time and space for these individuals to ruminate and think. Interesting solutions happen when you are bored and have taken your focus away from the daily fires. At CloudBees, product managers, designers have a day called “Product Leader Friday” to work on projects that expand the understanding of a persona for themselves or educate the knowledge of internal teams or evangelise something they care about. I am writing this article on my product leader friday!

Summary

Standing out in a crowded market does not happen magically. It requires deep product thinking, organisational frameworks and executive buy-in and support to make it happen. It then requires relentless work guided by organising principles that have been laid out earlier. That said, if I summarise things, the nub really is about three key questions:

Who am I solving the problem for? What problem should I solve for her? What’s the best way to solve her problem?

Simple enough!