The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

Be flexible or break – the case for outcome-driven development

Is the traditional roadmap that carefully details all tasks to be done in a quarter or even a year becoming obsolete? Gijs Hendrix believes that a big update is required. The future is uncertain, and if you go forward with your nose in such a roadmap, you won’t notice all the opportunities around you.

To change this, you don’t need a better cartographer. You need a different attitude. Listen to Gij talk about:

• the relationship between product vision and outcome-driven development,
• the importance of multi-level alignment in working with outcomes efficiently,
• the role of product discovery in fostering an outcome-driven organization culture.

The upgraded roadmap and a written discovery artifact are simply the result of these considerations. They’ll come to you when you least expect them to, so make sure to stick around and say hello to Gijs!

About Gijs

Convious – the vision to help and inspire

Sławomir Turkiewicz: Hello Gijs. Thanks for taking part in CTO vs Status Quo.

You only started at Convious last September. The company delivers a platform that helps tourist attractions offer a great digital experience to their clients. How do you prepare yourself for the role of a CPO in such a highly specialized industry?

In my previous product roles, I’ve worked on horizontal products used widely in various industries and companies. One key challenge with a horizontal product is choosing what to focus on.

A typical startup might try to get as many customers as possible. It might end up with customers in 10 industries in a few years. Then, it might discover that these clients have very different needs going forward.

One of the reasons why I joined Convious is that it operates in a predefined niche. The customer base is much more clearly defined in a model like this.

Of course, there’s still a lot of variability in the leisure market. But overall, the customers, whom we consider our partners, are inherently more aligned with the products I worked on before. That makes it easier to create value for a lot of customers at the same time.

The variability is definitely there. You serve theme parks, zoos, museums, wellness centers, and waterparks, to name just the most important types. Each place faces unique problems. A major one seems to be providing a specialized product to each one while remaining easy to use for everybody.

As you said, horizontal products struggle with that in particular. But can Convious really avoid overcrowding its apps with features with so many customer types?

What all our customers have in common is that they have an operation to run, which takes up a lot of their time. Typically, they’re not in the software business. They don’t have large IT teams. 

We need to provide them with an e-commerce and marketing solution that provides a great visitor experience and saves them time. Therefore, it must be easy to use for their operations. We always remember these assumptions when we build features, which helps us retain our focus.

Some features are complex by necessity. It’s a powerful tool. Certain product parts are only useful for a select customer base, such as the ability to use time slots.

A big theme park with a capacity for 10,000 people can use the feature to allocate time slots to reduce long queues. But for them, it’s not a critical feature. They have plenty of room to accommodate people during the whole day.

By contrast, the space available to an indoor playground is much more limited. What’s more, people come over for a specific amount of time. Time slots are critical to running a business efficiently and orderly in a setup like this.

To combat feature overcrowding, we offer different configurations so that partners don’t waste time sorting through features they don’t want to use.

So, despite serving a specialized market, you still have a lot of flexibility.

You could say that. Moreover, we noticed that these different customer verticals could learn from each other.

One of our customers is an indoor venue that provides reality experiences. Those take place in small rooms. The customer uses the time slot feature to offer several time slots with a limited capacity – they can only fit so many people in a room. For them, time slots are critical. They need to make sure they don’t sell too many tickets, but at the same time, as many as they can. It’s directly tied to their revenue. As we support them with this, we notice that other partners also begin to express more interest in time management.

One zoo began offering a different experience in addition to its traditional general admission model. It allows you to help a zookeeper feed animals. This experience is similar to the VR venue, involving small groups at specific time slots.

The zoo followed another of our customers’ examples and created an innovative product and experience. This shows how we, as a software vendor, can help cross-pollinate ideas from one vertical to another by showcasing examples and highlighting best practices through webinars and other marketing tactics.

Problems over features

Problems and features are what I wanted to talk about today. One of our first guests, Mika from Smartum, mentioned a project in which a discussion about adding a blue button led to building something else entirely. It turned out there was a smarter way to solve the problem. He advocated starting a product conversation by discussing user problems first.

Yet many tech companies still assemble a feature roadmap for months or years to come. Why do you think this happens?

The question of whether you should be output-driven or not has been answered by now – outcome-driven development is well worth pursuing. This approach reduces waste and helps the team use their time more effectively. However, companies struggle to bridge the gap between theory and everyday practice.

To begin with, going from zero to full outcome-based development is too big of a change. You need to do it gradually.

Product management, in particular, likes showcasing perfect examples of outcome-driven teams. It generates a lot of anxiety among people in an environment where they can’t just abandon feature roadmaps. Criticizing them is not helpful. That’s why I’m a big fan of the Toyota Way pillars – respect for people and continuous improvement. It’s about making steps in the right direction. You’ll be amazed if you look back a year from now and see what you’ve achieved.

Moreover, outcome-driven development can’t be initiated from the bottom up. The initiative has to come from product leadership. They need to explain to everybody why this is relevant and begin implementing changes in the day-to-day workflows.

Let’s explore why companies use feature roadmaps instead of an approach based on user problems.

Some blame leaders’ tendency to impose their will on people. They want to dictate a list of features and see them implemented – a top-down approach. I wonder how prevalent this approach is today in the era of self-managed teams.

Companies aren’t democratic. If the product leadership doesn’t support moving away from the feature-based approach, individuals can’t change their mindset. However, if you are in a position of power, you can do a lot to foster a change gradually.

You need to create positive examples. You may promote data analytics and the use of data to inform low-level decision-making. If you get good insights about what people do with your product, you have something you can use in a discussion with the rest of the management.

We keep talking about the Roadmap. The word suggests that there is a road you can travel on to some destination. But it seems that you must build the road when you want to innovate. Is the roadmap simply a wrong metaphor?

I think it’s impossible to remove the expectations from the word roadmap. So, personally, I’ve decided to keep the word but change its meaning a little and push it in a better direction. We also have a roadmap at Convious. There are two reasons.

First, in the B2B world, big customers have pressing needs. They need to estimate when you’ll be able to meet them and some clarity about timelines.

Second, the product and engineering teams also need some clarity about the order of things. So does the marketing to produce promotional content and whatnot. It’s about coordination.

I decided to challenge the traditional roadmap – the kind that has an aura of great specificity about it and tells you what you’ll be doing on August 23rd this year. A roadmap like this is always a lie because it’s set in the future, which is uncertain.

The answer I found is the now-next-later roadmap. As the name says, it only specifies what to do now and in the immediate future. It may also include a list of things on our radar that will be specified later. These items should only have vague, vague timeline commitments.

This approach is in line with what John Cutler calls suitably detailed roadmap items. The immediate item on the timeline is detailed, but things get increasingly vague as the timeline progresses. The current and next item should describe what problem it solves, who it is for, deadlines, and everything. The rest is much more vague. Of course, each statement should still start from a problem, not a feature, to make it align with outcome-driven development.

That’s one way to make a roadmap more flexible. It’s worth considering because I believe communicating about what you do and when it will be ready is still necessary.

Some believe that the pressure from stakeholders also contributes to the current landscape. Investors or top-level management want to know where you’re heading. They don’t want to hear that you’ll figure it out as you go.

Exactly. That’s why you should communicate with investors using the vision rather than the roadmap. Here at Convious, we have the vision to change the leisure industry. The roadmap is just a result of this.

It takes work to tell a good story that makes sense to everybody. You need to start by explaining why you exist, then move quarter by quarter and show a logical progression of your efforts. You explain what you focus on now and what you might be into in the following years. This sets priorities for the moment.

Speaking of your company’s vision, it looks like it recently helped you secure another funding round. Why do you think investors chose to believe in you?

We talked about what’s interesting at Convious earlier. The same value proposition that excited me to join the company also attracted investors.

Of course, I’m talking about our clear focus on a specific type of operators and on improving their visitor experience. Our reason for being, so to speak, is so evident that the vision almost writes itself.

Outcome-driven development is the perfect tool to make the vision come true. You have challenges, and you need to figure out a list of short—and long-term outcomes or goals to achieve to overcome them. So, what is outcome-driven development to you?

It ensures that every minute spent in the development process contributes to the company’s goals. And the goals, as you said, come from the vision. But let’s get a bit more specific.

The primary purpose of outcome-driven development is to prevent waste on the product side. You waste your engineers’ precious time when you build something the user or your organization doesn’t need. Few organizations can afford to do that in the long run, especially startups or scaleups.

As a leader, you need to make efficient choices. There are two levels to this: high-level and low-level.

On a high level, you have decisions such as: Should you proceed with a geographical expansion or focus on an existing customer base? Or should you invest in improving system stability or new features? At Convious, we may concentrate on operators or individual ticket buyers. On a low level, it’s about finding the best way to proceed in a chosen high-level direction. It involves the selection of technologies, methods, and processes. 

Outcome-driven development helps you and compels you to set these high- and low-level objectives, but it doesn’t determine how to achieve them.

Outcome-driven development – metrics

Let’s discuss outcome-driven development, then. Committing to an outcome instead of a feature sounds good on paper, but it may not be easy to implement. Achieving an outcome should create business value, which must be measurable to verify.

How do you choose the best outcomes to follow?

I tend to view these choices as bets. As a management team, you have to make bets, and each one has significant consequences for the product.

One such bet for Convious was geographical expansion. We currently operate mainly in Northwestern Europe. Some data suggests that the US could be an attractive market for us. We’re betting now that focusing time and energy on enabling a US expansion is more important than other outcomes we could pursue.

There is no easy way to determine the best outcomes for your company. You need a good sense of your company’s goals and vision and then pick business metrics associated with them. When choosing goals, as a leader, you will have to say “no” many more times than you will say “yes.”

Once you define those goals, you must figure out how to enable them. That’s when you get to more of the low-level outcome-driven development.

In my experience, the more time you spend figuring out what you want upfront, the less time you will need to build the feature. The chances you’ll make something that provides true customer value increase, too. That’s why at Convious, we always do thorough research and discovery before we start writing any code.

How many such outcomes should a company choose when it first takes this approach? Should it begin with one or two outcomes or go all out from the start?

No fixed number exists, but you shouldn’t choose too many outcomes simultaneously. You can only prioritize so many. It depends on the size of your company and the nature of your product.

I see how this prioritization poses some challenges. When one team prioritizes page load as a metric, they may propose removing some features that positively impact UX or conversions.

How to prevent this kind of conflict of priorities between different metrics and teams that champion them?

I’ll be upfront and say that it’s way easier to do in a smaller company. My experience also comes from such companies.

But the same principles apply everywhere. You need a good balance of team autonomy and the ability to resolve conflict between outcome-driven teams pursuing different goals.

On a process level, you must discuss upfront what you’re going for as a company. Each team can take part in these discussions and suggest outcomes that align with the overall direction. Quarterly goal planning is one way to do this in practice.

Other than that, it’s about people communicating on a day-to-day basis. Team leads and product managers should talk to each other about outcomes. If they can’t conclude, they should go one level up and involve top management.

In my practice, if you have a reasonable expectation of how people contribute to the same goals and a reasonable planning process, you can avoid major conflicts in outcome-driven development.

Outcome-driven development – process

How to build a process for outcome-driven development? What are the necessary steps that allow for continuous refinement of priorities based on measurable outcomes? 

I think it starts with a mindset shift. A feature-factory-type company is not going to become outcome-driven overnight. It puts a different kind of responsibility on people.

The delivery part can take care of itself, but the discovery part, where we make sure that our assumptions make sense, requires a lot of thought. 

At Convious, we made it so that we need specific information available before a new feature can begin development. I can act as a gatekeeper and say: First, I want to know more about it. I want there to be an artifact that outlines the problem statement, the feedback we got from partners in our research, the competitive situation, and the description of the problem we are to solve.

The artifact is just plain text. I’m a big fan of writing stuff down. You avoid the vanity of creating fancy slides and other visual content forms. This document quickly aligned everybody around the objective. Making teams write more stuff down in a structured way can also lead to all kinds of downstream improvements. You can create a gradual process and culture improvement around it.

As people adjust to this approach, you can add more tools to the discovery process. They may concern subjects such as data, user interviews, training, or even simple checklist-type tasks to be completed before you green-lit a feature.

You mentioned alignment. No matter how clear-cut your outcome-driven approach is, you must consider the big picture – yearly goals or KPIs. Otherwise, it may be hard to achieve organization-wide alignment.

How do you ensure that each team’s tactical outcomes stay in line with the big picture?

Having big-picture goals is one thing. But there is one more aspect of alignment. Teams will distribute the tactical outcomes properly as long as they communicate well with each other.

I don’t want to sound like I’m bashing Scrum. There’s no inherent problem with Scrum. We use it for day-to-day work. But I have to say this – too many processes can be harmful.

If you try to use processes to solve all issues, the development process becomes a series of hand-offs and communication via tickets. Getting feedback in such an environment takes a lot of time. I believe that it could even be called an anti-pattern because it compels people to stop talking to each other. Instead, they speak with departments, inboxes, and phone lines.

A system that revolves around tickets or handoffs can make a small company feel like a big company – inefficient and cumbersome.

Avoiding this process fatigue is important for your outcome-driven development. You need to move quickly and efficiently rather than waste time on processes. They can slow down your development so much that it can be almost as detrimental as building the wrong thing.

The retrospective meeting could be a great time to reflect on the existing outcomes and propose new initiatives based on them. How do you use it at Convious?

We do retrospectives, but they’re very team-specific.

I think it’s important to consider retrospectives on the entire process, not just the last two-week sprint. At Convious, we make extensive retrospectives of the whole feature. They concern topics such as what the discovery process looked like and how we got to the final shape of the deliverable. These insights can inform future discovery. And that’s how it all comes full circle.

Of course, this is an ideal scenario. We’re not there yet, but that’s our direction.

Outcome-driven development – mindset

On more than one occasion, you mentioned the importance of a mindset shift in fostering outcome-driven software development. How do you sell people the idea?

After all, some teammates may enjoy doing what they are told. Before, they had to meet a deadline. Now, they are directly responsible for the company’s success. Or do you need to hire people with the right mindset for it in the first place?

A culture change is always tough to conduct. Some leaders might be aggressive about it – get with the program or look for something else right. Personally, I like to lead by example.

My approach is to explain, communicate, showcase, and demonstrate how it’s done and where that makes sense.

As for individual attitudes, I noticed that any organization has some people who quickly adopt the idea of outcome-driven development. You can achieve a lot by rewarding them and showing their mindset as an example.

Take the written artifact that I mentioned as an example. We call it the shaping docs because it borrows from other experts’ and content creators’ various frameworks and ideas. We take in the shapes of their ideas and put them into our discovery practices. It wasn’t successful when it first came around, but then one of our product managers decided to try it. He got my support, and we discussed it widely across our company’s communication channels and in face-to-face conversations. And it took off.

Keep in mind – you don’t have to get everyone on board from day one. As long as people are willing to experiment, you can foster an outcome-driven culture from there.

As for hiring, there are situations when it is a good idea to consider getting on board more people who already have experience working in an outcome-driven environment. Similarly, you might consider partying ways with some people who really can’t change their mindset over some time.

However, if you can’t get a person to try outcome-driven development at some point, there may be a problem with your organization’s culture or leadership skills.

Resources

Can you share some books or online resources that shaped your views about and around outcome-driven development?

Marty Cagan’s Inspired and his follow-ups are interesting. They’re suitable for people who are new to outcome-driven development. You have to be cautious and not take his advice too literally. I mentioned the risk of losing flexibility by following processes too closely. Instead, you should get inspired, as the title says. 

Continues Discovery Habits by Teresa Torres – I would recommend this one to a vast audience because it has practical tips and frameworks for the product discovery side of outcome-driven development. As I said, I believe that this aspect is the hardest to master.

Lenny’s Podcast is an amazing series that always features inspiring people. You can use it to learn about product development in general and the outcome-driven approach in particular.

What’s next? Three actions for CTOs to take

Are you ready now to drive the actions and mindset of your teammates toward a desired outcome?

Remember:

1. Take care of product vision – there is no perfect way of ensuring that the outcomes you chose are the desired outcomes, but if they correspond with your vision, it’s very likely!
2. Align your people – use formal means, such as quarterly outcome planning, and informal ones, such as removing unnecessary processes and encouraging people to communicate as much as possible.
3. Improve your discovery. Being open to change is one thing. Determining the best direction is another. Polish your discovery process and incorporate customer feedback to inform your decisions.

The now-next-later roadmap will help you achieve the flexibility to respond to data and changing circumstances. The written discovery artifact will help you better inform your future moves – continuously improve it.

Most importantly, lead your outcome-based team by example!