The world around us is filled with uncertainty. Everything is changing so rapidly, that we cannot predict what even the near future will bring us.
And we all know that there is something that our companies need to embrace to thrive in the era of uncertainty, or at least to survive – and this something is, of course, innovation!
Innovation is a hot topic nowadays (well, and for a long time before). Many companies create cool departments with cool names like Innovation Hub, Corporate Accelerator, and positions like Innovation Manager, Head of Innovation, and Chief Innovation Managers.
Our CEOs routinely use expressions like Innovative solutions, Disruptive innovations, Innovative Company, at all-hands meetings or company-wide newsletters. It is not cool to admit, that company is not innovative. So far, all is great.
And how many of us think that we work at innovative workplace? When was the last time when we participated in some innovation creation? Last year? This quarter? This month? This week?
But what is innovation?
According to Wikipedia “Innovation is the practical implementation of ideas that result in the introduction of new goods or services or improvement in offering goods or services.”
That’s it. Very simple.
So it is not rocket science, but something that our companies do every day.
Who is the source of innovation?
People with the word “Innovation” in their title? Like “Innovation Managers in Corporate Innovation Hubs.” You have this word in your job title or job description, and suddenly, a secret source of innovative ideas is opened to you.
Probably, it is not exactly like that. And well, while quite many people with titles like this might indeed be catalysts of innovation or facilitators, coaches, and educators on the topic of innovation within a company, it is not them who can be real creators of the best innovative ideas.
Who might be those innovators?
And here they are, those who might be the real source of innovation for technology products. Those who day in, day out are diligently doing their coding, testing, deployment, regularly doing stand-ups, planning, reviewing, refining, retros – cross-functional agile teams including Software Engineers – a lot of different activities – and maybe innovation is not quite one of those activities.
They might see themselves sometimes as innovators in technology – but in product – no.
The product is for those business people. Product owners, product managers, business analysts, and some mysterious stakeholders. Those people know what is needed to impress the customers and users, what their needs are, and in general – they know who those customers and users are.
Have the developers ever met the customers? – “Oh, thanks god no! Not in my job description”
Over the last two decades the agile way of working became prevailing within many cross-functional teams in the software development industry. Still, most of those teams can be called really cross-functional end-to-end teams just so far, as what they are mostly doing is just transforming a set of requirements received from outside, usually from stakeholders, into working software.
We value the time of software engineers and would like it to go to the coding as close to 100% as possible and not to “waste” it for other activities. And sadly, many engineers think the same. They just want to put their heads down and write code leaving all product-related stuff to the business. And the last thing Software Engineers themselves want to do is meet the customer.
Cynefin
Let’s look briefly back to uncertainty and current realities through the Cynefin framework.
While product development is clearly located in the Complex domain – which means emergent practice, probing, experimenting etc., in many cases, we are handling it as it is a Complicated thing: a group of experts (businesspeople) analyze a problem and come up with a solution. And way too often, analyzing a problem is actually limited just to collecting some wishes and features from stakeholders – sales, marketing, CEOs and creating some Roadmaps of those features.
The modern product development is much more than this, or better to say something very different than this. We need to understand a problem, ideate, experiment and learn – and here, the vast potential of very intelligent, creative, and educated people who could contribute to the company’s innovations on an everyday basis mostly stays unused. Usually, these people have a Software Engineer job title.
It all starts with Product Discovery, and continues with it. The Product Discovery is a never-ending process; it is done in parallel with product development and it involves a lot of uncertainty, problem statements, ideation and experimenting.
And we use them here (show them on the right side) but we mostly don’t use them during the discovery.
And those diligent workers are immensely capable of coming up with ideas and planning the experiments, and meticulously running those experiments with a scientific approach.
Roles accountabilities shift
In software product development, the roles accountabilities have been traditionally:
- Product people are responsible for “What to build?” -> The Requirements
- Engineers are responsible for “How to build?” -> The Code
Isn’t it time for Product people to concentrate more on understanding and communicating “Why to build?”
- What problem are we trying to solve?
- What benefits solving this problem will bring to our customers AND to our company?
- What opportunities do we have currently in the market?
And then, together with Engineers, elaborate “What to build?” to solve the problems and chase the opportunities.
As Software Engineers are surprisingly capable of coming up with creative ideas, validating (or invalidating) those ideas and developing innovative solutions.
And many of them are really willing to do so.
However they almost never get the opportunity to participate in Product Discovery.
Why involve engineers in Product Discovery?
1. Diversity of perspectives helps to generate different ideas
One of the reasons is obvious – to have more ideas and different ideas.
We need to generate many ideas to start with, from diverse perspectives, to go beyond familiar options and to start thinking creatively. And later, we need to choose the most promising ones to validate and experiment with. But the first step is to have a significant pool of ideas to choose from.
And here engineers, being creative people, not only are able to come up with many great ideas, but they can also bring quite different insights than product people do, just because they have different perspectives.
2. Engineers often generate the best solutions.
Another reason is that engineers often generate the best solutions.
According to Teresa Torres:
“When it comes to generating solutions, engineers often come up with the best solutions. This surprises a lot of teams.
It’s not because engineers are the most creative or the smartest people on your team (even if some of them think so). It’s because they have a depth of knowledge about what’s possible with technology that often surpasses everyone else on the team. But there’s a caveat that we need to consider here.
The best solutions are the result of understanding what’s possible with technology and understanding what our customers need. So if an engineer is going to leverage that depth of knowledge about what’s possible with technology, they also need to build up a depth of knowledge about the customers’ context. The only way to do that is to participate in discovery.”
Also, your engineers might have a better-structured process for problem-solving than just about anyone else in your organization, and that’s truly where their power, insight, and creativity in solutions come from.
3. Engineers often ask disconfirming questions
One important and interesting reason is that Engineers often ask disconfirming questions.
As Teresa Torres put it:
“As we work with our product ideas, we tend to fall in love with them. It’s human nature.
As a result, we tend to ask confirming questions. We look at all the reasons why the idea will be a wild success. But to find the flaws in our ideas, we need to ask disconfirming questions. What might go wrong?”
“Use your engineers who are good at asking disconfirming questions to help you identify your underlying assumptions. Invite them to participate in a pre-mortem for each of your ideas. Ask them, “Imagine we built and launched this idea and it was a colossal failure. What went wrong?” Your engineers who are great at seeing the flaws in your ideas will excel at this.
Engineers tend to be strong at asking disconfirming questions because it helps them catch error cases or edge cases in their code. It’s a skill they practice regularly. Take advantage of this and invite them to participate in discovery with you.”
I really love this idea of pre-mortem workshop, and we have tried it with several teams. Usually, it is an event with a high level of energy and a lot of laughs, as people become really creative with generating “evil” ideas. At the same time, by the end of the pre-mortem, very serious outcomes are always generated – identified risky areas or assumptions where we had been too optimistic.
Engineers are the masters of critical thinking.
4. Engineers bring an analytical mindset to product experiments
After identifying our assumptions, we can formulate hypotheses that we need to test as soon as possible, starting from the most important and riskiest ones.
For this, we need to plan experiments. Not just experiments for the sake of experiments but those that would help us validate or invalidate our assumptions. Then, we need to run them with a scientific approach to provide reliable results. And for this strong analytical skills are needed.
According to Teresa Torres:
“Many product managers and designers are strong analytical thinkers and can be well-versed in these areas. But software engineers, because of their engineering backgrounds, are more likely to have a stronger background in statistics and scientific thinking.”
What is more – many engineers absolutely LOVE experimenting. This is something where their creativity, ingenuity, critical thinking, and problem-solving capabilities can be applied to the fullest.
And here, very important is the role of product people: having deep knowledge in the area of product experimenting, they also need to help the engineering team gain this knowledge: what kind of experiments exist, where it is better to apply them, and how (e.g., A/B tests, fake door, landing page, prototypes/MVP, etc.)
5. Engineers can quickly assess the technical feasibility of the ideas at hand
They can right away come up with a fast initial assessment:
❓How difficult is it to implement it?
❓Is it possible to build at all?
❓What might be a rough estimation of efforts needed?
6. Engineers will have more empathy for customers and will feel more engaged
I believe this is the most important reason to involve engineers in Product Discovery.
Building empathy with customers helps us understand customers’ needs, challenges and desires in order to create good products to address all these.
However, another important benefit for Software Engineers is that empathy creates a drive and motivation to work hard on searching for the best solution and to build a great product that will improve the customers’ lives. Having empathy towards customers, getting this personal touch, and understanding their everyday struggles and pleasures brings meaning to our work and creates more satisfaction with what we are doing – when we know that it will really impact the life of somebody we know.
Besides, Engineers who participate in Product Discovery have buy-in to what the team is going to create. They were there when the ideas were shaped. They feel heard. They influenced the solution. Probably making it more innovative and smarter. And this creates engagement.
How can Software Engineers (safely) build empathy with customers
Communicating directly with real customers might be one of the best ways to do it, either through interviewing or observing their behaviors. However, it might be too challenging for many engineers to start with.
So there are also other, less scary, ways that help to build empathy fast, your team could try:
→ First, understand who is your customer:
→ Ideal Customer Profile
→ Persona
→ Create Empathy Map
→ Go to Customer Support/Call Center
→ Watch recordings of user sessions
→ Listen to recordings of user interviews
→ Observe a colleague using a product
→ And eventually – Participate in a real user interview 🤘
Possible objections
Despite obvious benefits, it would be naive to believe that everybody would support involving engineers in product discovery right away.
By Management
❗️ “Engineers are too valuable and expensive resources”
First of all, let’s stop calling people resources! I love this saying “If you call people resources, be very careful – they might call you overhead” 😜
❓“Should not the engineer be writing code?”
Software Engineers generally don’t like to be considered just “code generators”. They are capable of contributing much more to creating great production in addition to their straightforward responsibility – writing code.
❗️ “They don’t have time”
Actually, participating in Product Discovery doesn’t require a lot of engineers’ time:
1. In average 1 hour per engineer per week
2. Naturally, some engineers will be involved more, some less
In the beginning, it still will take more time: for educating, training, discussions (why and how), agreement making, facilitating the first attempts, but later when it becomes a part of the process, it will feel like a natural sequence of events and an organic way of doing work.
❓“Who will develop?”
If an engineer contributes to designing a good solution that will have a real impact on the business instead of building something that might never be used, it seems to be quite a good trade-off, right? 😉
As Peter Drucker famously said: “There is nothing so useless as doing efficiently that which should not be done at all.”
❓“Should not the engineer be writing code?”
Software Engineers generally don’t like to be considered just “code generators”. They are capable of contributing much more to creating great production in addition to their straightforward responsibility – writing code.
❗️ “They don’t have time”
Actually, participating in Product Discovery doesn’t require a lot of engineers’ time:
1. On average 1 hour per engineer per week
2. Naturally, some engineers will be involved more, some less
In the beginning, it still will take more time: for educating, training, discussions (why and how), agreement making, facilitating the first attempts, but later when it becomes a part of the process, it will feel like a natural sequence of events and an organic way of doing work.
❓“Who will develop?”
If an engineer contributes to designing a good solution that will have a real impact on the business instead of building something that might never be used, it seems to be quite a good trade-off, right? 😉
As Peter Drucker famously said: “There is nothing so useless as doing efficiently that which should not be done at all.”
By Product Managers
Most Product Managers do appreciate and support the involvement of Software Engineers in Product Discovery, as they experience many benefits of it right away – from having a variety of ideas and technical support while elaborating the solution to a much higher engagement and buy-in of engineers.
However, some Product Managers, in addition to having the same concerns as management does (“They are a too valuable resource,” “They don’t have time,” “Who will develop?”), might also have, so to speak, a “Radical Ownership” attitude:
“It is mine!”
(💍 “My precious”💍)
They might say:
❗️“Yes, it is good, but engineers don’t understand the customer context”
→ So, the role of the Product Manager is to help Engineers to understand it.
Or:
❗️“Yes, but their ideas are not really viable”
(where there is a tiiiny probability that it might mean “My ideas are better” 😉 )
→ Don’t speculate which idea is better; plan experiments and test both ideas instead.
Product Managers will still be the main experts in Product Discovery. But with great support, a lot of ideas and the engagement of the team. We all know that Product Manager is one of the most challenging and busy job roles, so an extra pair of hands and brains will never be a bad idea.
By Software Engineers
“We are here to write a code!”
Involving software engineers in Product Discovery is a significant shift for the engineers themselves. Often, many of them prefer to focus solely on coding, leaving broader business considerations to others. It’s a familiar routine: heads down, immersed in the world of code.
However, it is true for most engineers that the more they get involved in Product Discovery, the more they see its value and enjoy the process. They gain a deeper understanding of customers’ struggles and successes, feel that their input is being heard, they have participated in the creation of the solution, probably making it better and more innovative, they feel more engaged and empowered as a result of this.
How could we start with making this happen?
As with all the changes, we need to adopt a gradual, step-by-step approach rather than imposing Big Bang change (“From the next year, all the engineers will participate in Product Discovery”).
→ Socialize Product Discovery – start discussing why it is important to bring software engineers into the fold of Product Discover – not just informing them about the process but also engaging them in discussions, understanding their perspectives, and fostering a shared understanding of the importance of Product Discovery in the development cycle.
→ Educate engineers on what Product Discovery is, and teach its basics, such as User-Centric Approach, Problem-Solution Fit, Ideation and Validating Ideas Through Testing, Designing and Running Experiments, Prototyping and Creating MVPs to test hypotheses and gather feedback instead of creating big bang shiny solutions
→ Find enthusiasts among your engineers — there are always a few who are more open to trying new approaches. These are often more senior engineers who, having spent considerable time coding, also recognize the importance of being knowledgeable in the business domain.
→ Begin with a pilot team – identify a team who would be a good fit for it and is willing to experiment. This will normalize Product Discovery practice within a team, and other teams will have fewer biases toward it. As other teams observe the successful implementation of this approach in this pilot team, they’re more likely to want to join in, not willing to be left behind.
→ And most importantly: Help engineers realise that AI will eventually replace those who want just to write code 😉
Leave a Reply