Digital transformation and Product Handshakes
Introduction
Digital transformation is the state within which a lot of large organizations find themselves in or in need of, as technology, business and user needs evolve into their new iteration. If you think about it, life is an iterative process where stimuli creep into our lives and change it little by little every day!
Companies need to follow that evolution as closely as possible or run the risk of becoming obsolete.
Digital transformation is the way to follow that evolution of the triangle between humans, business, and technology in a meaningful way. This is an iterative process and that would imply that digital transformation is perpetual and not a one-off where there is a beginning and an end.
This article encapsulates personal thoughts from reading and hearing a lot about companies’ experiences with digital transformation process and the journey towards valuable products.
“Product” = Value
What is a product?
It is easy to overlook the fact that no matter how many years you work with products, you might have never had to provide a definition for it. Until you do! Then you get to the terrifying realization that you are mumbling something that might or might not be true and quite a lot of it is just your idea.
That is a slightly sad day for a product designer. It is the classic “missing the forest for the trees” phenomenon where we are so focused on the specifics of requirements, research and prototyping that we might not have the time to stop, take a couple of steps back and reflect on what a product actually is!
Searching online for a definition you can find a lot of different definitions with, thankfully, a lot of overlap between them such as:
- A product is tangible
- A product is something that is marketed and sold
- A product satisfies a need for its intended segment etc…
But what about internal products? Are these products? And how many of these, so called, attributes do they need to fit into to be considered products?
These are tangible, depending on your point of view whether code is tangible. For me code leads to something tangible because “tangible” is from the user’s point of view not mine, as well as code is an output towards a desired outcome. What about marketed and sold? We do not sell the tools we build for our colleagues, and we do “market” them but not in the same way as products for commercial purposes. So then are internal tools and applications products?
At this point you might be thinking “why are you bothering with labels? Who cares whether you call it a product or not.”. I would agree with you except it does matter to the people put in charge of “products” and for product designers. In the enterprise space, a product is tangible but it is not sold but I would still consider it a product as long as it serves a specified need or set of needs our dear colleagues and business have.
What is value?
What is value? How do we measure value? How do we shift from thinking about output to thinking about outcome (value)? How do we do it in an effective and efficient way?
The shift to value is not an easy one. Being able to measure value means we know whether we are providing it or not. Measuring whether we have successfully provided value to our consumers means we have to talk to them, get to know them and be great at receiving feedback.
Also, measuring success on outcomes means that we will know for a fact whether we are succeeding but also whether we are failing and that is not something we necessarily want to find out!
To paraphrase the well-known phrase “Value is in the eye of the beholder” so in the eye of our target audience and the business we work for.
How to be value-minded at scale
The mindset change requires, in my opinion, a structured approach where we are trying to change behavior.
There are two types of organizations. Those who understand human behavior and plan for sustainable behavioral change for the better of the company and their people and the companies who do not understand behavior and force changes. Transformation is hard and there is no one recipe that will ensure a smooth transition.
What I do know is that behavioral change is adopted by its intended audience. For that, the value/effort ratio needs to be positive from the perspective of those this change affects the most. For human beings to calculated relative value, they need to know what is in it for them and how it affects their daily life and outlook as individuals.
But how do we start this process?
Well, as i said i do not know of one recipe to ensure success. My opinion is start slow and make a plan where the previous step ensures the logical progression into the second step. So:
Adopt a lean product canvas for your products.
The lean product canvas is a one-page template where you provide information about your product, its audience (amongst other things), expected value and other relevant information.
How to sell it? The canvas’ good selling point upwards is that it is a one-pager that will give your managers/executives a summary of everything that is important about the product and the value it provides in the glimpse of an eye without the need for long PowerPoint presentations and a lot of talk.
The template itself is not important, what is important is the discussions that it will spark in the organization and the need for research about your product, its value and who it is serving. Logically, looking at the canvas, teams will start realizing how much they do not know about their product and its audience and then next logical step is to fill in the gaps.
Make a plan for research and product discovery
Who we think our end users are, what we think their main problems/opportunities are, maybe build a proto-persona or two and then do actual research to validate all these assumptions about your customer segment, the problem space and the persona you just built. Of course, you could just do research to start with and not make a great deal of assumptions. Sometimes though, our stakeholders have an idea of who the end-user is and what their problems are as well as how to solve them, so we can take those assumptions as they are and validate them.
Once this is “done”, then we need to ideate on potential solutions to these problems/opportunities.
Build product teams and make them as autonomous as possible.
Granted, fully autonomous teams are not plausible (in my opinion), but we need to have people from the business embedded in the product team. We need that osmosis between business and engineering.
We need product OKRs based on what the business wants to achieve (Strategic KPIs).
Without having people from the business in your team, you will be forced to make a lot of assumptions and the back and forth will not be smooth. Both you and the business will waste a lot of time and energy. It is important that the product OKRs are based on business objectives and built collaboratively with them.
The above mentioned “steps” are not necessarily in the order presented but they may work in certains organizations that are not value-driven but they want to be.
Be smart, look around you and see what people are most likely to accept and frame your message and proposition based on that.
Teams, OKRs and Digital Transformation
If you are thinking that, so far, it sounds like digital transformation is complicated and difficult then you are absolutely right but it is a necessary change!
Behavioral change requires time and “pressure” at the right time, for the right reasons and “sold” to people from their perspective (adoption). It also structures a well-thought of communication strategy with good selling points from the employer’s and employee’s perspectives alike.
Digitally transforming a company, also means that we want to start following best practices and be prepared for the future in terms of digital architecture, engineering and product design and development. During this time, enterprise areas such as infrastructure, digital security or the “old IT org” that looked like the “old, boring kind of IT” now take a front-row seat to this “theater of operations” called the digital transformation.
These areas are the ones providing the tools and services to engineers (all types of digital engineers) and others, to do their job and enable them to provide value in a different and better way that also prepares the company to evolve at the same pace as our target audiences. Teams responsible for i.e APIs, cloud, developer experience, product design and digital security tools and best practices, are areas that should and will affect how everyone else does their job in a more efficient and effective way.
The user centric approach of these areas will determine whether these beautiful and useful products and services we spend so much time and money building will actually be adopted or not.
Adoption is key
This might not be as easy as you might think it is. It is based on the user centric maturity of these teams.
People adopt things they find useful, easy to use and if the value/effort is worth it.
Hopefully, we are all familiar with the Technology Acceptance Model(TAM). The TAM describes adoption as a function of perceived usefulness and perceived ease of use.
Calculating the perceived usefulness before and after you launch something would be a great way to benchmark an MVP or prototype you build to prove or disprove a hypothesis.
Adoption, though, is a two-way street. The team building a great product who is to be used, for example, by every engineer in the organization needs to be focused on the adoption of it. Putting focus on adoption will help the team put effort into it.
- How do we communicate with our users?
- How do we establish feedback loops with them?
- Who do we involve?
- How do we co-create with end-users?
All these questions come into focus but how do we translate meer interest to action?
My proposal would be to push for products such as APIs, cloud, security, developer experience, product design etc.. should have adoption specific OKRs. Make it official! If there is an OKR there will be a responsible person(s) for moving it forward. Tasks will be official in the backlog for transparency. Sounds like a great idea, right? It is, not because its mine but it makes sense. Although, this is only one part of a handshake. A handshake requires two parties and two hands! We need the other half of this “handshake”. But how?
This is where the idea for Product Handshakes comes into play.
Product Handshakes
Especially for transformational products and services like APIs, cloud, developer experience, digital security, usability/UX etc and all horizontal functions, we need the teams who should be adopting these (most of them) to have adoption OKRs as well. Now it is not only about your team extending their hand and pushing adoption forward but also the receivers of these technologies and services to extend their hand to receive. This is what I call a Product Handshake.
Why do we need these Product Handshakes?
Our teams have dependencies and these dependencies can seriously impede our progress. How often have you thought:
“We have a dependency with team B. We had a meeting and they have added our request into their backlog.”
Well, if you have thought of that or waited for a team to get to the part of the backlog that is relevant to your product then you know what I am talking about. These teams have their own priorities, goals and OKRs. Yours are not the highest priority. How do we align priorities across teams/organizations to ensure the adoption of these transformative digital technologies are going according to plan and we remain on the same page? Make it official! Make it a priority. Even make it part of your overall organizational objective or North Star (whichever framework you are working with)!
How to do Product Handshakes?
Could different teams with different product visions and OKRs work them together? That might present issues, right?
Products might have different visions, different end-users and context so how do we do this?
The solution is to adopt the O from OKRs. That is to have a S.M.A.R.T objective for adoption that would allow the individual teams to figure out their KRs (Key Results) based on their own context. As long we “hit” the same objective(adoption of a technology/behavior), we ensure we are moving towards it. All we do is use the same target on the wall. How you “throw the darts” towards that target is “your” business.
I know what you are thinking.. “Sounds great but what do we do if we are adopting something another function/team builds that might be of low quality?”
That is a fair question, and this is where the TAM comes in(mentioned above). If something is useful and usable then we ensure, at least, a big part of its quality and usage.
Conclusion
Digital transformation is a complicated endeavor whose outcome is the change of behavior and adoption of future looking technologies that allow companies to evolve themselves as fast as human beings’.
Adoption is key for any product whether it is internal or external and that is particularly relevant for all the companies out there undergoing a digital transformation. Do not rely on changing behavior by force because that will not yield the long-term results you are looking for.
Product Handshakes are a thought experiment to ensure adoption is in the agenda, it provides a common objective for the teams who have to work together and put efforts into adoption to make it work. It also allows receiving teams, the freedom to realize this objective the way they see fit as the experts of their domain and contextual constraints and status.
Try product handshakes out and please provide feedback on your experience of how they work, what works and what doesn’t and lets evolve the concept and make it reality.
I am looking forward to sparring about these ideas and get your constructive feedback and comments.
