Product improvement: don’t get dragged into pointless discussions!

Lately, we had an intense discussion about how to improve our product (an application). The result was frustration and a feeling of wasted time. I asked myself why?

And then it clicked in my mind: I got dragged into a discussion that started all wrong!

Let me explain. The discussion started with someone suggesting an improvement with a technical focus, along the line of “this is the feature we need to add to our app”. Others proposed alternative features arguing the pros and cons of their solution. The discussion went from bad to worse as ever more features were put on the table.

With hindsight, we clearly had no chance of having a successful discussion because it started all so wrong! From experience, the best improvement ideas are generated by focusing on a concrete problem, exploring this problem space thoroughly before generating ideas to solve this problem. In other words, by following the design thinking principle. But not only do we need to start with the problem space, we also need to avoid a technical focus and start with a “high-level” view of the problem in the context of the customer experience / business processes.

My learning? I have created a simple model to illustrate my point.

Model to guide the product improvement dialogue

To avoid useless discussions about product improvements, assess in which quadrant of the model the discussion is starting. If it’s not in the 1st quadrant, then reframe it to focus on the problems on the customer experience / business process level (quadrant 1). Once a common understanding is reached, then it’s time to assess how the current product relates to the problem (quadrant 2). From there, the team can formulate ideas that solve the problem on the customer experience / business process level (quadrant 3) and finally discuss what needs to be changed in the product to better support this solution (quadrant 4).

Do you also get dragged into discussion that start in the “technical-solution” space?

systemic.ch – Joel Tendon

Advertisement

Design thinking raises interest

Amazing how the below post published on LinkedIn is raising interest from my contacts. Over 2’400 views and counting… It shows the deep interest that people have for digital ideas and projects happening in their vicinity.

The learning curve also works for scaled agile transformations!

In Swisscom’s “problem-to-solution” agile release train, we have now completed the third program iteration (PI) planning. All participants agreed that there has been a marked increase in the planning efficiency and focus on business value. This is a testament that the learning curve works not only for single individuals but also for large groups and in the context of agile transformation. I strongly recommend the SAFe methodology to all enterprises that want to “go agile” at scale.

Developers are hired for their IT skills and fired for their (lack of) social skills

Picture from 123RF.com

With IT underlying all digital transformations, software developers are increasingly becoming strategic assets. And yet, in most companies and IT departments, there’s something fundamentally wrong in the way developers are being hired and integrated into teams.

The problem comes from the belief that only IT professionals can assess other IT professionals. I’ve seen for myself how IT professionals & IT managers with LOW SOCIAL SKILLS go about recruiting new developers solely based on their assessment of the candidate’s IT knowledge, analytical skills, past developments and “nerdiness”. And they completely forget – or are simply not able to – correctly assess the social skills of these candidates.

There’s a fundamental problem when IT managers with low social skills lead the assessment and hiring of new developers.

This way of hiring IT professionals leads to very nasty surprises over the long term. Indeed, I’ve seen many bright developers (from a technical perspective) with important social “blind spots” being hired and ending up costing the organization dearly in the long run. Here are some typical problems that happen when developers lack fundamental social skills:

• Transparent, open and ongoing communication doesn’t happen. Communication must be managed painstakingly and via a constant effort that ends up wearing down the other team members.
• Casual conversations or debates easily escalate into emotional arguments that leave long term scars on the relationship between team members.
• Precious development time and effort is wasted when a suborn developer insists on a solution that ends up being sub-optimal. It gets worse if some misplaced pride leads him and the team into a “creeping commitment” dead end.
• A toxic subculture of “we the IT knowledgeable” vs “they the useless business guys” can grow and spread throughout the organization.

So how can we avoid hiring developers with superb technical but low social skills? Here’s a simple idea:

• Identify IT professionals in you company – not necessarily managers or team leaders – that have HIGH social skills.
• Integrate them in the recruitement process to meet and exchange with new candidates.
• Take into consideration their assessment of the candidate’s socials skills when deciding on which candidate to hire.

Building IT teams with developers that have higher than usual social skills will lead to much better team performance, stability and quality of the IT development over the long term. New IT skills can always be learned on the job. IT developers do this all the time to master new tools, frameworks, libraries etc. Social skills however are much more difficult to learn and depend on a person’s own motivation and willingness to reflect, learn and modify his behavior. That’s why it’s time to start paying attention to the social skills (or lack thereof) of developers before hiring them!

The level of social skills available within an IT team is the main predictor of it’s performance over the long run.

Planning in the age of agile

Today, Swisscom’s “problem-to-solution” release train finished its first program iteration (PI) planning. This was done according to the SAFe methodology – a scaled agile framework for enterprises. Over 100 people – of which 6 development teams – planned and committed to the features and stories that will be implemented over the coming 10 weeks (5 x 2-week sprints). I’m proud to have supported this process by assuming the product owner role for a development team.

Cadence, transparency and alignment are the core principles that will now guide all teams to deliver business value.

Expect such planning events to become commonplace in Swiss corporations…

Is This The End Of The Business Process?

Throughout my career, I have approached business transformation via the mantra “process follows strategy, structure follows process”. As far as I can remember, the preaching from management gurus was: “First, define the business strategy. Then plan, implement and improve business processes to assure the effective and efficient delivery of products & services”. In other words, perfection comes via the mastery of repetition. Business success hinges on defining the optimal sequence of streamlined activities that deliver the goods.

With processes, perfection comes via mastery of repetition.

Will this approach still be as relevant in the future as it has been in the past? I’m not so sure. Let me explain why.

My latest area of focus has been the transformation of the support/assurance processes for a major company. The ultimate aim: instead of solving failures (incidents) when the customer calls, failures are avoided altogether by detecting situations leading to failures and proactively solving them before anything bad happens. As you can image, there are plenty of opportunities to implement machine learning analytics in this context. After many meetings with many specialists such as process engineers, business and data architects, data scientists and many other clever people, I truly see the possibility that the “process approach” may be on the way out.

OMG, where did the process go?

How could we possibly manage a company without processes? This is how it can happen.

The first stage towards a “process light” vision is to push the key decision-making within processes to machine learning algorithms. If x and y occurs, then do activity z. The benefits of doing this are huge: once implemented, you can basically keep on improving the decision-making over time, and thus the entire process, without having to change your front-ends, back-ends, activities, roles etc.

In a second stage, activities are broken down in ever smaller parts. The learning system is expanded to consider ever more data (relevant customer data, business interactions, diagnostic data, historical data etc.). At this point, the sourcing of data and building of analytics become ever more important. That’s where the energy and resources are invested. The result is an ever greater number of “process variants”. Each customer case is being handled differently to obtain the best possible result for the particular customer and circumstance.

This transformation, pushed to the extreme, can lead to a third stage where pre-defined activities don’t matter any more. Quite the contrary, in this new data driven decision-making context, each decision and task is tailored to a specific customer situation. The enterprise is freed from the constraints of traditional processes. Business efficiency and effectiveness isn’t driven by the optimization of tasks any more, but from the optimization of data sourcing and analytics.

In a data driven approach, business success is driven by mastery of data sourcing and analytics.

People working in the organization are not linked by common workflows and systems, but receive their instructions in a timely, case-by-case basis. Imagine employees simply receiving instructions via a chatbot on their PC, mobile phone, augmented reality devices or earphones! Processes and workflow systems disappear, replaced by a central big data & machine learning cluster. People and systems don’t make decisions – or guide the customer experience – based on “what has been defined in the process” but simply implement the instructions coming from the “central brain”.

The slow decline of the business process

Does this sound crazy and farfetched? My answer to that is yes and no.

On the “yes” side, I can testify to very concrete projects and results for the first two stages of the above described transformation. I can also attest to serious attempts being done to implement the third stage. Seeing is believing as they say.

On the “no” side, I can see barriers that slow down this transformation or make it uneconomical in certain cases. Setting up a big data cluster and a robust team of data scientists is a major undertaking that requires investments with many 000’s and over a long time. Furthermore, on the business side of things, creating new knowledge and integrating this knowledge into a customer experience is difficult and doesn’t happen overnight. It’s the result of a “learning journey” that is fraught with trial and error and incremental improvements. Another barrier is that replacing activity based processes by data driven instructions requires scale to work. It’s a valid approach for big companies with many customers in which some processes are repeated hundreds of times daily and for which a data trove can be collected and made available. Scale matters. The data driven approach is neither technically feasible nor economically viable for smaller organizations or units with small amounts of cases being handled every day.

My conclusion is this one. The vision of a centralized big data brain that pushes out timely “next best activity” instructions to multiple touchpoints via connected devices is definitely not farfetched any more. The transformations to get there have started in major companies. The attention and investment directed at such approaches will keep rising in the foreseeable future. This data & analytic approach to business management has the potential not only to improve processes but to replace them altogether. So be prepared to witness the slow but gradual disappearance of the business process in data driven enterprises.

The vision of a centralized big data brain that pushes out timely “next best activity” instructions to multiple touchpoints isn’t farfetched. The transformation to get there has started in many companies.

What Can Startup Founders Learn from Project Managers?

What do you need to pay attention to when launching a startup? I was asked this question recently from an aspiring entrepreneur. Both of us having a strong project management background, I replied that “kicking off and managing a startup is like managing a project”. The more I explained the life of an early stage startup and compared it with managing a project, the greater the similarity between both became obvious.

Les pratiques clés pour mieux gérer l’innovation

Dans un contexte en évolution rapide, l’entreprise qui ne veut pas être distancée par ses rivaux, doit sans cesse adapter ses produits, processus, systèmes de gestion et compétences. Le moteur de cette adaptation, c’est l’innovation. Pour maintenir une longueur d’avance, il faut non seulement que l’innovation ait lieu, mais qu’elle ait lieu de manière efficace. Pourtant, la gestion de l’innovation reste un domaine mal connu, en proie à de nombreux débats dans lesquels les théories se multiplient et se contredisent parfois.

Quelle structure adopter pour doper l’innovation?

Faut-il structurer l’organisation selon une logique hiérarchique ou selon une logique de groupes de projet? Dans un environnement en mutation rapide, les managers se trouvent souvent confrontés à ce dilemme lors de réorganisations de groupes de travail ou de l’ensemble de l’organisation.

Stratégie d’entreprise: entre “fit” et “stretch”, quelle approche choisir?

Hamel et Prahalad ont été des pionniers pour préciser deux démarches fondamentalement différentes servant à formuler la stratégie d’une entreprise.