• Bjarne Jensen

Agile Multi-Disciplinary LEAN UX design TEAMS explained...

Interdisciplinary UX design TEAMS explained is your new Service Design, Design Management and Design Thinking Agency and IoT-consultancy. We solve it-challenges for private and public organisations into Sustainable IoT & AI. For info on how we work, UX analyse and CX design your business & it-challenge visit

12 views0 comments

User is Hero by IoT supported shopping experience

"Leaders must keep in mind that the customer is the superhero and your job is to tell them how your product will help them become a hero." (Donna Lichaw)

The history of product innovation has repeatedly shown that companies who ignore the user in favour of the technology fail. They fail because they fall victim to what is now known as the ‘stack fallacy’. (read on article)

Slack, Uber, Facebook, Google, even Microsoft have proved Sharma right. Success in any given market always comes down to the same fundamental question, “Who understands the user better?”

Product managers have traditionally discussed products in terms of solving problems. But in a hyper-competitive world it’s no longer enough to simply solve a functional problem. You need to understand your user’s story.

Which is why it’s gratifying to read Clay Christensen's recent book 'Competing against Luck' in which he revisits his theory of Jobs-to-be-Done (JTBD). Almost 20 years old, it's the ‘newest old idea’ in product. Only now is it being fully appreciated by a new generation of digital product designers.

JTBD’s perennial relevance stems from its singular focus on the context, mindset and desired outcomes of the user, rather than the attributes of the product itself. It’s a form of storytelling, with the user at the centre of the narrative rather than a peripheral player. Product practitioners who embrace the method start by articulating a product’s ’Job Story' before considering design details.

Christensen points out that companies that view their business through the Job lens are much less likely to be disrupted by upstart challengers, in the way hotels have been by AirBnB or taxis have been by Uber. Teenagers have always wanted to communicate with each other in private. Once they passed notes to each other in class, now they send messages via Snapchat.

The user’s Job Story rarely changes. It’s the means of achieving it that is dependent on the technology available.

Christensen is adamant that Job Stories are 'discovered' (rather than written) and that they have both functional and emotional components.

For a product designer, the Job lens shifts one’s focus away from features to the outcomes users can expect to achieve from using your product. It also transforms one’s understanding of the competitive landscape.

Traditional marketers tend to focus on superficially similar products. As a consequence, product teams tended to compete solely on features or attributes: more memory, less sugar, a better camera.

Reed Hastings views Netflix through a Job lens. His understanding of where they compete is expansive:

"We compete with everything you do to relax. Think of any night you did not watch Netflix. We compete with drinking a bottle of wine. That’s a particularly tough one."

Whale's Justin Kan is more brutal in his assessment:

"Startups mostly don't compete against each other, they compete against no one giving a shit."


Article by

9 views0 comments

Agile Operating Model for SmartCity

Let me start with a definition of agile as it applies to operating models or processes: “being able to turn on a dime for a dime” and “being able to change faster and more cheaply than your competitors”. These phrases are taken from Craig Larman, who was part of the team who coined the term agile as being relevant to the lean and six sigma community. In this community, agile is associated with short-period (often six-week), test-and-learn projects, at the end of which priorities and direction can be reset based on what has been learned. It is also associated with “minimum viable product”: the way of testing a new idea.

So what has it got to do with operating models? First, when making changes to a process or an operating model, an agile approach is probably wise. Instead of planning it all out and then executing, an agile approach involves making some changes quickly, then reassessing, then making some more changes: the fire, aim, fire aim approach rather than the ready, aim, fire approach. Of course, in many tall hierarchies, the agile approach to change is hard to make happen because, to get approval for change, top layers in the structure often want a fully-worked and costed business case and plan. Changing the plan and the business case every few weeks is hard both administratively and politically. So one of the implications of agile is that we need to have decision processes in organizations that focus more on “intent” rather than “plan”, and decentralize achievement of intent down to teams that can operate in an agile way.

Second, there are lots of components of an operating model that are not, and never will be, agile. In fact success in period A is often a function of your willingness to make commitments now that may cause you to be inflexible in period B. Think for example of a company competing to win a supply contract from Tesco or Walmart. To win the contract, the company often has to demonstrate that it has built the capacity and developed the systems needed to serve the customer. This capacity and technology can then become legacy problems if the customer changes its needs in subsequent years. Yes you can build flexible capacity and systems, but typically these are more expensive than dedicated solutions. So there is a trade-off: more agility can raise costs and reduce the chance of winning the contract.

The choice of the head of the organization is another example of a decision that is typically anti-agile. Every leader has strengths and weaknesses. If circumstances change so that the weaknesses become a significant disadvantage, it typically takes a year or two before the leader can be changed.

If we think through the components of an operating model – processes, organisation, location, information, suppliers and management system ( as explained in the Operating Model Canvas) – we can see the tensions that agile raises. A process needs to be “leaned” to deliver a particular value proposition efficiently. But this will make the process costly or less effective for delivering slightly different value propositions: leaning the process can make it less agile

Organization structure, even if controlled by holacracy (the self organizing methodology), takes time to change: in other words any form of organization is in part anti-agile. But, at the same time, complete disorganization is even more anti-agile.

Location is expensive to change not just because of leases and the moving of people and equipment, but also because of other elements of the operating model that are influenced by location – supplier relationships, customer relationships, attractiveness for employees, etc. So location can be a major source of rigidity. One of the attractions of the ‘cloud’ is its lack of location.

Information systems are frequently a cause of rigidity. When managers talk about legacy systems they really mean systems that constrain their ability to change. There is frequently no way round the problem. Off-the-shelf software applications often force the organisation to operate in one way. Bespoke applications, because of their cost, can introduce even more rigidity.

Supplier relationships are frequently anti-agile: effective relationships take years to build and cannot be abandoned at a week’s notice.

Finally, management systems and scorecards can be anti-agile. An organization that has been driven for ten years on a metric of sales margins, will take some years to convert to a return on capital metric or a sales volume metric.

So, when we design operating models, we are often deliberately designing in aspects that will be anti-agile.

This does not mean that the agile thought is unhelpful. It causes us to think hard every time we make a design choice, whether the choice is increasing or reducing agility. The simple question to ask is “once the new design is up and running, if circumstances change, how long will it take to change to another design both from a political and executional perspective.?” The shorter the time frame the better. But we will still often make choices that are anti-agile (take months or years to change) because of our need today to drive lower costs or improve customer benefits.

Contributed by: Andrew Campbell , Mr , Ashridge Executive Education

Director of Ashridge Strategic Management Centre part of Ashridge Executive Education which is the executive education arm of Hult International Business School. Program Director for courses Advanced Organization Design and Designing Operating Models. Consultant to large and small companies around the world. Director of Sonae, Portugal's largest...

12 views0 comments
Featured Posts
Recent Posts