Digital Product Management

‍

High-performing organizations have already figured this out.

It's not enough to have a website. They want something from the site!

It is not enough to have an e-shop. They want something from the e-shop!

It is not enough to have an information system. They want to get something out of the information system!

No one wants the web just to exist. Spending energy, time and money and at the same time not wanting a positive impact on the organization does not make sense!

Logic is one thing, reality another. The intention of the contracting authority and its approach to the creation of digital products often go completely against each other.

Making a digital product is simple. Establish an approach to its management, thanks to which the product has positive impact on the organization, it is challenging and requires self-awareness, competence and experience.

Modernization de tecnologia senza política e simplificación del proceso é borderlino usátil

-- Jennifer Pahlka

The following article addresses Managing digital products so that they are really useful to you. It's challenging and a bit abstract. So it is advisable to clarify the most important concepts.

1. Digital product = web, e-shop, application, information system...
2. Output = what is to be done. Landing page, banner, slogan, photo.
3. Outcome = how we want to influence the people out there to make an impact on our organization or the world. People send requests, read our articles, register for webinars.
4. Impact = positive contribution to the organization. Higher turnover, profit, brand value,...

‍

What is your approach to digital product management?

We meet two fundamental directions of digital product management. I'll cite this on the example of the site, but it also applies to all other digital products. Of course, both approaches have many nuances, so take them as illustrative.

‍

Approach 1: Control by outputs

1. We look at competitor sites,
2. we put together a list of what we want to have on the site,
3. let us build the site based on our requirements.
4. We adjust the colors, photos and content of the banner on the front page according to the wishes of the management.
5. We launch the website and we're done.

‍

Approach 2: Management by results

1. The key people in the organization agree on who and how we want to influence with the new site.
2. We understand the people out there in the context of our business.
3. We find their needs, aspirations or problems.
4. We will design as small a site as our organization can handle it,
5. we'll test it with people out there
6. we launch it
7. and we'll start to see how we've managed to influence people
8. and in the long term we are looking for new ways to change their behavior.

‍

Approach 1: Project management by output accounts for an estimated 90+% of digital products in our country. We can see it from inquiries, cases, references & digital products out there. At the same time, it is a relic of the past, from the times of mechanical control and omniscient management.

Approach 2: Project management by results is in the minority and it is nice to see mmj. on the top 1% of digital products that roll everyone else. It requires a significant change of approach, and that is challenging. It is, ironically, much less about money and much more about ego and taken rails.

Driving by outputs is normal and that is its greatest danger. It was summed up nicely by Simon Wardley:

If 67% of generals bomb hills then what should you do as a general... a) find a hill and bomb it! We like to copy others, it gives a false sense of security, doing the right thing etc. That's why we have surveys, MQs, etc.

Normal procedure acts safely. Everyone does it that way. That is, except for those who do not, that is, 1% of current or future winners. They are aware of the fundamental difference between digital and physical products.

We make a washing machine, we have customers, we make money. We make a digital product or add a new feature to it and very often nothing happens. If the behavior of the people out there doesn't change, then change doesn't make us money, it just consumes it. Worse case scenario, we're causing problems for people out there that weren't in the product before. See all the major website redesigns in the last decade.

Let's go through both approaches in more detail so that you are more aware of their differences.

‍

Approach 1: Control by outputs

The goal is to get things done. At the beginning of the project, you dictate a list of things that should be part of the digital product — whether you copy this site in style or as a PDF with requests. Someone will add it. You check that everything you wanted is there. It's done.

• The output is clear for a long time ahead, it acts stably and statically.
• The project is essentially linear. Requirements > Implementation > Startup.
• We deal with the scope, deadline and budget.
• We're not dealing with a positive impact for the organization or the people out there.
• All responsibility for the impact of the work lies with the person who dictates the requirements.
• If the task force dictates them, then no one is responsible.
• All suppliers are ready for this approach.
• The project ends with the launch. Ideally on time and on budget.
• After launch, a phase of technical maintenance and expansion follows according to new requirements.

Funzioni può essere finalizzato e fornito e funzionare perfectamente, ma non viene essere qualsiasi valore

-- Joshua Seiden

Our entire industry is based on contractors doing exactly what management wants and assuming that Research and strategy have already taken place. Management, in turn, assumes that Best practices and supplier expertise will solve everything. Both assumptions are wrong on most projects.

As a result, ideas for digital products arise impulsively in the heads of the working group and copying the competition. And that has a catch. Most ideas don't work, even if the task force, the CEO and external consultants agree on them. All these people are smart, but smarts aren't enough -- as the quote below illustrates.

The vast majority of ideas fail in experiments, and even experts often misjudge which ones will pay off. At Google and Bing, only about 10% to 20% of experiments generate positive results.

— Ron Kohavi, HBR

Surprisingly few of the things we make up off the table have a real effect on the behavior of people out there. Ideas are a commoditywhich, moreover, everyone has in unlimited quantities. Unfortunately, they mostly don't work.

However, today this approach is leading, and managers face the fact that management by outputs is the only option. We have the resources and time to lose money and almost no system to make it. People aren't used to scrutinizing (potential) customers/users/fans or judging the consequences of their decisions. As I wrote at the beginning — making digital products is easy, changing your own approach is challenging.

‍

Implications of Approach 1

• The decision-maker or other people on the client side have no idea what really bothers the people out there who are supposed to use the product.
• A not insignificant part of the finished outputs is useless from the beginning and is used by a minimum of people.
• In the case of applications or information systems, many functions require modification after the first time the client uses them. Multitasking is coming.
• We don't measure, we don't evaluate, we don't learn from the data what actually worked.
• The implementation team is in the role of a shovel, doing what management dictates to it.
• What doesn't work for people out there doesn't get talked about. Often we don't even know.

‍

Examples from the life of the House of Cutter

• Demand: “We need to price a PDFKo with a list of requirements by tomorrow. “
• Demand: “We like site X from your references, make us one too. “
• The potential client has 5 million CZK for the implementation of the system and 100 000 CZK for the design of the service.
• The potential client re-embarks on the same process three times and expects a different result.
• We audit the web. 1/5 pages — that is, several thousand — no one has ever seen. Another 2/5 saw units of people. Hundreds of days of wasted time creating content.
• A potential client working agilely has 100+ change requests in the buffer, but no one has ever talked to a single user.

‍

Approach 2: Management by results

The goal is to change the behavior of people out there. Outcome management is based on the assumption that the ideas implemented have a negative benefit for the organization if they do not affect people's behavior in a way that is beneficial to the company. So instead of making lists of things to implement It addresses where there is a problem or need to be solved by a digital product and how it succeeds.

• The core of management by results lies in understanding the business and the people out there and systematically verifying that we are going in a beneficial direction.
• The form of the outputs is postponed until the last moment, when we know the most about the context of people and business.
• The team (designer + programmer + product manager) gradually learns what works and what doesn't and shares responsibility for product performance to management.
• Every idea is taken as a bet, and the team finds out how the bet turned out.
• Only a few external contractors handle the procedure.
• The minimum version of the product is launched. Often just as a dysfunctional experiment. In the case of websites, we run as small a website as possible.
• Work begins with the launch.
• The process is cyclical and essentially endless. Context > Prioritization > Implementation > Evaluation > New Context...

‍

Results management has been used by the most advanced companies in the industry for decades... so you won't be the first or the last. On the other hand, it doesn't just go by itself. Approach 2 is much more competence-intensive.

The first step is to start systematically gathering information about the people out there you want to influence, because it doesn't make sense to shoot ideas blindly. Results-based management requires marketing/user/design research and verifying that we are going in a good direction on the data.

Your most unhappy customers are your greatest source of learning.

-- Bill Gates

Who's supposed to do that? From that you have in the team the product manager of the digital product. Site Manager. Manager of the e-shop. Manager of the information system. It is not possible to outsource this role. Na researching you can hire an outside agency as well and learn from it, but anyway someone has to take their findings and work with them for the long term.

Okay, we have a hunch about the people out there. And it is necessary to start working with the opportunities found, set a strategy and start experimenting.

This requires an environment that:

1. He has a clear direction
2. It is safe
3. People can and want to learn in it

One example for all.

Imagine,

1. that you come to your boss,
2. you tell him X didn't work out
3. and he will give you a reward for it in the quarter (!).

‍

Almost unimaginable, isn't it? You can say something didn't work out and still get a bonus for it.

The reason is simple — if you want to move forward fast enough, you have to bet on the edge and take risks. Logically, sometimes you fail. Do you remember? 10-20% of experiments come out. But those who come out will pay you handsomely for the rest.

Sure, you're not Google, so you're doing your product in a more stable environment, but still don't go with expectations above 50% of successful ideas. Most of what you come up with doesn't work out the way you would like. And you can learn from it. It's still faster, cheaper and safer than working blind and just getting things done.

There is practically no such environment in public administration, only very sporadically in companies. I don't know of anyone in the Czech Republic who requires employees to smartly they were failing and giving them bonuses for it. I know of many organizations where failure is penalized and thus classified and masked. And we're back to managing by outputs because it's much easier to launch a site than to cause it to have a positive impact.

94% of the problems lie in the system set up, 6% are people's mistakes.

-- Edwards Deming [paraphrase]

Do you see where this has taken us? Changing the approach requires new roles, a completely different approach to working with uncertainty or even significant organizational changes.

‍

Consequences of Approach 2

• Changing the approach to the objective leads to a discussion of roles, responsibilities, orientation in a complex environment, evaluation, experimentation, environment in the organization, work with uncertainty...
• You build a long-term competitive advantage. Knowing the real needs of the customer and what did not work out has a direct impact on turnover and profit.

‍

Examples from the life of the House of Cutter

• Instead of ending the collaboration by launching a website, we help the client build competencies for online marketing for the following years. Today, marketing activities completely fill his business pipeline.
• We help the client to get data into analytics, which corresponds to 99.5% of orders in ERP. When you want to experiment, you need to see reality.
• Instead of the graphic design of the new e-shop, we conduct experiments with the client and increase its short-term and long-term turnover before the redesign begins.

‍

What do contractors say?

Service providers make money selling time and materials.

‍-- Jeff Patton

Suppliers are ready to supply you with things, that is, outputs. Few will guide you through a results-driven process. “Tell us what to do and we will do it” is the standard. Suppliers are able to price it, order it, deliver it. In IT projects with a tolerance of ± 400%.

In the tender process, the ratio of suppliers is about 10:1 in favor of those who supply outputs, among other things, because you have built your demand from the beginning.

And that one contractor starts suggesting things to you that you're not interested in. They value research and not the creation of the whole solution. It will force you into rethinking team roles. Instead of a project, the need for a project and a process suddenly arises. You are not prepared for any of this, so you go to the safe option. When 67% of generals are bombing hills, it's time to find your own hill to bomb.

The standard contractor-supplier relationship is nicely illustrated by the sentence: “We hire you so we don't have to test”. When you want results, you hire a supplier just to make sure it gets tested. Multiple times. Because it's a way to work with risk and uncertainty.

Sometimes it happens that after the end of a project you remember that you actually want results. Perhaps because demand fell by half. You go to your supplier and he logically defends himself. Responsibility for the results lies with the person who dictates the requirements for the outputs. I mean, you. Don't you have competence? Didn't you know? This is not a supplier's problem.

‍

The goal determines where the energy goes

The choice between outputs and outcomes has a huge effect on everything else.

Goals determine where people's energy goes.

Are you focused on delivering things? Things arise. Their production and maintenance costs money. Thus, they have a negative benefit until it turns out otherwise. And it doesn't show up because you've never really evaluated it. The point of output is its existence.

Are you focused on influencing people? People's behaviour is changing. Or they don't change -- and you try to do things differently to change. Because it often doesn't work out the first time.

Focusing on outputs in your organization is easy to recognize. The team meets the demands of the supervisors, and you all kind of hope that they know why you're supposed to be doing this. You have a list of 60 changes, but you don't have a single interview or test.

Management thinks well — everyone else has that auto-rotating banner on the site, so it must work. Unfortunately they don't have to. Fortunately, no one evaluates the behavior of people within your digital product, so it doesn't bother anyone either.

But it should. Since you've read this, maybe other companies in your industry have done it too. It's time to move forward.

‍

Q&A

‍

We don't have time for any research. We just need a fast website.

Okej.

‍

Okej?

Everyone is an architect of their own happiness.

‍

We're not Amazon, Alibaba, Alza or similarly sized companies, so it doesn't make sense to us.

As I wrote before, the most difficult thing is to change the approach. It's not a question of money — you need to put energy into your own self-education to begin with, not with external contractors.

‍

We don't have money for uselessness...

“Putting $2 million into an app that doesn't bring anything to the company seems like a great investment”. No one ever said. But at the same time, it happens all too often...

‍

Where is Agile? Outcomes or results?

This depends a lot on the implementation of agile methodologies. The vast majority I've seen are just and only about the outputs. Management says what programmers are supposed to do and they do it. In cycles. Research, analytics, experiments, customer value... they're not standard parts of agile and the team is kind of hoping management has it done.

‍

We are doing a combination of both approaches...

My experience is that you can't have both. Management wants demand. Sounds like a focus on results. At the same time, it dictates the exact content of the site and requires a rotating banner to hang on the front page. Unfortunately, no one has ever studied the people out there, because after all We know our customers. This combination is just a dream of results. Reality is useless outputs.

‍

We manage the product according to the outputs and it's cool.

It is possible that you were lucky. Some organizations have it. I recently read on twitter that almost any book on business could be called “How in retrospect it makes sense to me that I was lucky”. It is possible that your cool means you don't have the slightest idea.

‍

Our environment is safe. Everyone can have their say.

When was the last time you verified this? Try for example Safety checks by Liz Keogh.

‍

What competencies should a product manager have?

Depends on the level of seniority. It certainly includes communication, influencing people, decision making (in 80% of cases it's not sensible to do it just intuitively), collaboration, ability to deliver things, marketing/user/design research, strategy.

‍

How do I get started with digital product management?

SVPG, Inspired, Lenny Rachitsky, Melissa Perry, Josh Seiden, Jeff Patton,...

For House of the Cutter we make an email mini-course available free of charge Digital project management and we hold several open thematic workshops — Goal setting, Strategic Research, Test workshop. And, of course, we help to manage according to the results client projects...