Not Even Wrong – Initial thoughts on strategy

July 2014
Stockholm @ the office

It’s been an interesting summer of reading. I was on holiday after all, so I gave myself a long leash and permitted my mind to wander. I ended up investigating my hunch that the way organizations think about strategy can have a profound impact on how they think about all the other aspects outlined in my model-in-progress. This is most certainly not a revolutionary thought, yet I felt I needed a bit more background on the very concept of business strategy to better understand the mechanisms that I sense are in play. I have a feeling that the underlying world view that constitute the basis of strategy is a bit of a blind spot for many organizations, to speak in terms of johari windows and all. I’m basically suggesting that many organizations unknowingly embraces strategic thinking that is based on world views that are not congruent with the world view of the organization.

This research led me down a path where I explored the history of business strategy, rather than the practice of business strategy itself. Mintzbergs Strategy Safari and Walter Kiechels Lords of Strategy were great companions on the journey.

On this journey, to my great and admittedly smug satisfaction, I found ample evidence supporting my long held belief that business strategy as a concept rests on rather shaky foundations. As you may know, there are several schools of strategy and they cannot seem to agree with each other on even the fundamentals. They are, as one author remarked,  “remarkably inconclusive”.

For anyone interested in Systems Thinking and Holism, the conception of business strategy becomes the starting point of it all, as every initiative or plan designed by the organization flows from the strategy – and more importantly – and this is my point – the strategy therefore carries with it the underlying beliefs that is allowed to guide the strategic process further into the fabric of the organization. It follows then, that identifying how the organization thinks about “strategy as concept” is a way towards understanding the fundamental world view that will, via the strategy, permeate the entire organization. I would venture a guess that this is not something that all too many organizations sit down and have a chat about, which further suggest that these underlying mental models and world views are left unexamined and most likely unknown to the organizations themselves.

Researching how the idea of business strategy itself -  and the later different flavors of strategy – emerged is immensely entertaining. For you who are happily unaware, suffice it to say that had you been there in the 1960’s when the idea of business strategy was conceived (in a joint effort of the management consulting firms and Harvard Business School) I would have excused you for remarking rather irreverently “Wow guys, you’re just making this shit up as you go, don’t you”. Because they were.

Fast forward a few years, and I would not have admonished you for saying “Wow guys, these things that you propose, they don’t really work do they?” Because quite often, they just didn’t.

One major take away from these studies is how severely  a classic prescriptive strategy mindset conflicts with the strategy-as-learning perspective. Implicit in the prescriptive schools of thought is the idea of strict hierarchies, top down, command-and-control and other – from my perspective – unwanted elements. The question I’m exploring is to what extent – if at all – the organizations’ take on strategy can be a constraining factor in our drive towards change and the future of work.

Further more, if the idea of generic prescriptive strategies is firmly in place in the minds of managers, there’s every reason to suspect that the dangerous idea of generic best practice also lands in fertile soil. The idea of organizations as complex adaptive systems finding themselves well within a complex context must seem awfully alien to such a mind.

To sum up: There’s a potential mismatch between the world view that created some of the strategy ideas now in use, and the actual world view of organizations. This might create dissonance. And as the novel practice of business strategy was exported to all corners of our globe, that movement seem also to have exported a set of beliefs and values that I deem to be detrimental to the idea of the modern workplace.

One might even say that they’re #notevenwrong

Earlier post on Not even Wrong

Not Even Wrong – Reality Check V: Guest Post: The biggest lessons from a successful software project

July 2014
Stockholm @ the office

Yet another great post from the Team that brought you the new Hemnet Map Search. This time by Stefan Lindbohm. You can find the original here

The biggest lessons from a successful software project

In my years of working with software projects the one thing I have learned is that doing software projects is really hard. Probably zero projects I have been part of or heard of has delivered their value, kept the quality to a standard everyone is proud of, launched on time and had a team of happy people through all of it. Recently, though, I was part of project that did just that. An actual real life professional software project that was deemed successful by both the team and the stakeholders.

I work at Swedish real estate site Hemnet. We are a company of about 50 people with about 15 people working in product development — mostly developers plus a few designers. Being a small company means we are close to management and all fill a bit wider roles than in larger companies. The biggest challenges in our organization has been making priorities and following them through. This heavily influences where we have put most of our effort and where we have made the biggest lessons making, though I think most of it can be pretty broadly generalized.

The team consisted of one UX designer, one graphics designer, one business analyst, one dedicated developer and me as team lead and part time developer. With the team of 5, we switched map providers, created a solution to render 100 000 hits on a map simultaneously and designed and implemented an all-new view for searching on maps. We did this in just 6 months and, from the release date set in the beginning of the project, slipped only one week with being fully rolled out.

Before we get in to what did matter, let me point out that you can Scrum, Kanban or Scrummerfall all you want without getting much of results. It’s easy to try to change the internal methodologies of a team because that’s something you’ve got complete control over. The biggest challenges though, are in getting the right conditions for the team and within the organization. Only after that is settled does methodologies begin to provide real value.

Here are the biggest things that made the project succeed.

A team with power to do its job

This is where everything begins. Way too often, projects are spread out over departments and even split in sub-projects over different departments. The business side is done in one project, handed over to a design project and then handed over to a development project. And even if that is not the case, people are still spread out without good means to focus and communicate on the project. This completely kills the common understanding and collaboration within a project.

Our team was created with exactly one premise: the goal of the project. We were to create the new map search experience on Hemnet. How would it look? Find out. How would it work? Find out. What would it even do exactly? Find out. This was absolutely crucial in enabling us to do our work — we are product developers and excel in solving problems. Based on the goal, the team formed the plan to do it, the concrete requirements and features and did all the design. Except for getting the rest of the company to buy in on our plan, we were never in need of someone else’s decision.

This of course requires the team to have all the competencies needed to get the job done. Having a team with a common understanding from start to end has incredible value in ensuring everyone works on the same thing and towards the same goal to create a cohesive product. In our team, having our business analyst from start to end allowed us to not stray away from business goals, and having everyone with from the beginning ensured we all really understood why the heck we were in this to begin with.

One of the factors we all appreciated the most was being all together in a room dedicated for the team and the project. If you are in an office, the change from being just one room apart is a huge boost to the social aspects of the team and the collaboration made possible by putting sketches up on the wall and just leaning over to talk about something is invaluable.

Making sure of a stable team with the right conditions is where everything begins.

Awareness of what could go wrong and preparation for it

Things always go wrong. The problem is that we more often than not ignore this and just plan for the best. This results in everything going to pieces when an assumption turned out to be wrong or an unforeseen problem arises. As a result, projects usually hit a point where everyone gets uncomfortable over something that went wrong and starts arguing over how to proceed — a situation where exactly nobody has their best ideas.

We spent a lot of time in the beginning of the project trying to figure out where things could go wrong. Being aware of the risks is key to being able to react in an intelligent way when something eventually goes wrong. In our case, we identified where users were most likely to have a hard time with the change and what business related key measurements we were most likely to impact. We completely shaped the project around the risks and made sure everyone understood and were prepared for the things that could go wrong. This helped us adapt continuously and completely avoid disasters, both in the product itself and among people in the company.

The plan we made focused on the key features that would be realized in the project on a higher level. This allowed us to cut the right corners in times when time started getting sparse while still delivering the value promised. We also spent time discovering where scope creep would most likely pop up and discussed these points beforehand. The things we agreed on not doing were then part of the plan. Designing the plan in terms of general features and including the things we would not do was a key tool for us in delivering the project on time.

Plan as much for the risks and the things you won’t do as the things you will do.

Collaboration outside of the team

All developers have been in projects where requirements and conditions change over their heads. A manager changes his or her mind on something too late in the project or another project gets important and starts snatching people. This is one of the most effective ways to demoralize a team trying to make something great and is probably also the most common way I have seen projects go out of control. The problem here is that managers often have no ability to make sense of cryptic scrum points, refactorings and vague descriptions of what is done and what isn’t, which forces them to make decisions with effectively no information on what they are deciding on.

First off, we put a lot of effort in communicating the plans for the project. We made sure everyone with the power to change our faith were fully aware of the plan, including what we would do, what we would not do and what we needed to complete the project. We did this early enough that we still could change everything and made sure that all stakeholders had their say before nailing it.

During the project, we continuously discussed any change that would affect stakeholders with them and held recurring demos open to anyone in the company. This allowed us to work without dropping anyone’s perspective. We had a number of small changes come out of this that would have gotten into big problems if they wouldn’t have been revealed until the end of the project.

Keeping managers and stakeholders in the loop is key to having the project stay it’s course.

There isn’t ever a silver bullet with these things. These were the biggest contributors to this specific project being a success. Even though I have reason to believe they would help significantly in many situations, a project always have to start with the people and environment where it will live.

We have the brilliant Thomas Lindqvist as our full time coach working on process and people since two years. This project is the result of those two years of experimentation and much of the reasons why it succeeded are the brainchildren of Thomas’ continued thinking on the matter. This may seem too obvious, but the best way to get better at process is to spend time thinking about it and improving it.

If you are interested in more on this particular project, Thomas has written on the “post-mortem” retro we held with the team, our graphics designer Daniel Feldt has written on his perspective of the project and our UX designer Magnus Burell had atalk on the UX side of things. And for the more technical side, our map-oriented developer Igor Tihonov will talk on this year’s FOSS4G in September.

Earlier post on Not even Wrong

Not Even Wrong – Reality Check IV: Guest Post: Creating a new map search experience

July 2014
Stockholm @ the office

My friend and colleague Daniel Feldt wrote a few words on one of our latest endeavors, and he was kind enough to let me post his text on these pages. You can read the original here.  

From my perspective, this quote is particularly heart warming:

“I’ve worked on web projects since 1999 with everything from web hosting to light backend programming to interaction design and visual design. That’s 15 years of experience – quite a lot in Internet years. …The new full screen map search is, by far, the most fun and successful web project I’ve been a part of. “

Creating a new map search experience

In May of this year a small team at Hemnet launched a new full screen map search experience for 1.8 million weekly visitors at Hemnet.se. From start to finish we researched, designed, built and launched the new search in six months. The new full screen map search is, by far, the most fun and successful web project I’ve been a part of. This is a short summary of how we did it, from a user experience designer’s point of view.

I’ve worked on web projects since 1999 with everything from web hosting to light backend programming to interaction design and visual design. That’s 15 years of experience – quite a lot in Internet years. During these years I’ve worked in everything from huge corporations to the smallest of teams, and one sure thing is that the product development process has almost never looked the same.

Some of these projects were successful. Some weren’t. Some projects were never-ending, with a backlog managed by Mr Creosote and thus exploding to a gooey mess when the last piece of thin mint gets added to the backlog.

I would certainly categorize the Hemnet Map Project as a success. Successful launch and satisfied stakeholders – but here is something that’s even more important to me: a happy, inspired and creative team from start to finish. A team that leaves the project hungry for the next one.

Setting up the team

To wildy paraphrase, we were told:

“Bring home the full screen map search*, create a beloved fullscreen map search experience with new possibilities for added functionality for the user and future ad revenues. And do it as fast as you possibly can.”

* previous one was hosted and developed by an external partner

We got the trust to set up a small and self organizing cross functional team – running fairly autonomous with regular demos and and go aheads with management. The team consisted of:

• Two designers – With a range consisting of user experience, interaction design and visual design
• One researcher – A freelancer helping out with interviews, personas
• One business developer – Concepts, ads
• Two developers – Ruby, map tiles, front end

One of the developers were also team-lead – keeping the whole thing together and on track. Note that this were our titles and main focus areas. But all team members were involved from the get-go in everything in the project.

Everyone had a say during decision making discussions and because we had the trust from management and had all the necessary knowledge in the cross functional team – we could take decisions right then and there ourselves. Eliminating the time it would have taken to report, present and get go ahead from management.

We felt a true ownership of the project.

Decisions were made with a shared understanding for the value we would bring Hemnet and with regard for the overall goal for Hemnet. The trust of setting up this team and managing this project came with a couple of conditions.

We had to:

• Have regular demos that the whole company could attend where we presented what findings we’d done (early in the process) or what we were done building in the project.
• Break down deliverables to smallest possible chunks and deliver them to the live site to reduce future surprises
• Have regular retrospectives where we talked about the projects progress, if we were happy, what would make us happier, et cetera.

The discovery phase or “to boldly go where no man has gone before”

With all this we moved into a discovery phase. Again, all team members were involved in every aspect of this. During a eight week period we defined goals and metrics for the projects. The success criterias were defined by the team, not the management.

We researched, found and verified insights thru surveys targeting our existing map search users to track their needs and behaviour, sifting thru behavioural data from site usage and phone interviews with users.

We co-wrote user scenarios and project specific personas. We visualized concepts together, gathered feedback and built simple prototypes.

In the end we had lots of findings, prototypes and good stuff to work with.

Implementation phase

At the end of the discovery phase we had a pretty good idea about what we needed to build and how to build it. The implementation phase started with a lot of planning. Splitting scenarios into buildable chunks that we could deliver to the live site whenever they were done. That reduced the number of late surprises compared to pushing a huge chunk of code to the live site.

Again we did a lot of things together. Sketching concepts and drawing responsive patterns on whiteboards and paper – quickly presenting our ideas, throwing them away, presenting new ones and honing the good ones. Everyone sat together in a room covered with whiteboards, and everyone drew. This is by far the quickest way to iterate design solutions instead of a single poor designer detailing a wireframe and risk spending too much time on a solution between design critiques.

I’ve seen, been a part of and also been the culprit in projects where the time between design critiques grew longer and longer. And if a single designer spends too much alone time on a solution you can almost hear the Deliverance-banjo playing in the background. That’s never a good thing.

We met the challenges of continuous feedback in several ways. We had bi-weekly demos that the whole company could attend, where we demonstrate what we were building.

Once every week, always the same day and time, we also invited whoever wanted to come to a “designfika”. If you are a Swede, or ever been involved with a Swede, you are aware of what a “fika” is. It’s generally an excuse to have a cup of coffee and eat buns. At the “designfika” we gathered in a room with coffee and pastries and the design team presented whatever they were working on at the moment. The purpose was to gather feedback.

In a way we are all designers. Designers solve problems and that’s something everyone can be a part of. The people with the title “designers” have the task of presenting what the problem is, how the design solves that problem and gather feedback on the design. But, I guess my view of the role of a designer and the importance of design critique is another blog post to be written…

The last part of the continuous feedback is one the most crucial. User testing. We employed several ways of user testing and as always: the more user testing you can do the better. We invited users to our office and did 10+ interviews and let them try out the project. Quite straight forward. Now we don’t always have the time and resources to do something like this, and you probably don’t either.

Quick tip: The easiest way to quickly get input is to test on people from other departments within the company – which we did. My colleague Magnus also put together a homework assignment for everyone at the company with a single page crash course in user testing with ready made questions so that everyone could test the product on a friend or a family member.

All this gave us valuable insight regarding how the product worked, and this is something you could easily do whenever you are designing something. Not only will you get valuable feedback on the product, but you will also spread the knowledge of user testing to other parts of the company. And I can assure you that the majority of your colleagues will have fun doing it and they will also (hopefully) feel involved and invested in the project.

The importance of A/B testing or “Scotty, what do you think, forward thrust?”

After nine two weeks iterations with continuous design iterations and lots of backend development we finally had a product to start A/B-testing. This was important for us because we wanted to make sure that the tech behind the new map search would hold up for traffic and how the flow of traffic would change and/or disrupt existing ad revenues.

With a product ready for A/B-testing we started to deliver the new map search experience to 5% of our traffic. We had launched the project. Now we started the process of analyzing the stats and gather feedback from the 5% of users using the new map search. We got our hands on a handful of browser bugs and some map tiles performance issues and spent the last couple of weeks polishing the product.

Throttle up or “Scotty, we are going to need everything she’s got!”

Now, there are something quite fulfilling with having a big bang release. Push that button and release this new product to a surprised group of users. Shiny, new and scary (if you ask the user).

But starting out with the A/B-test meant that release day practically meant throttling up from 5% to 100%. Maybe not as exciting as a big bang release, but way better for your nerves and it makes it possible for the team to enjoy a beer at the launch party.

Post release phase or “The final frontier”

Just because we launched the new maps didn’t mean we were done. There were still stuff left on our wish list that needed to be done. The live site were running our most viable product with some additions. But still a lot of stuff to do – UX goodies, performance enhancements and such. The backend team needed to spread the knowledge of map tiles and all the work they had done to the rest of the developers and the design team had style guides to update and communicate.

Our keys to success or “how to keep the redshirts casualties to a minimum”

To quickly summarize our keys to success and how we avoided “redshirt casualties”. We had easy access to everyone we needed to talk to, we got insights from users from our user panels and behavioral data from Google Analytics. We had all the necessary competencies in the team to solve the task, and we were the decision makers.

We were “hands off” from management and were able to focus on our task. We had time to plan, learn, fail and then learn some more. Designers programmed and developers were involved in research and design.

And we communicated. A lot. Everything in this post is about communication. Daily stand up meetings, spontaneous and planned design critiques and regularly retrospectives that gave us concrete actions to improve the project and keep us as happy as possible.

Built by five people in six months. We are extremely proud of the result. You can try out the new map search here or see a little bit more of what I did here.

My colleague Magnus Burell held a presentation called “UX at Hemnet” at the UX All Stars (Yes, he really is an all star) meetup – check out his slides on Slideshare.

Our resident guru Thomas Lindqvist recently wrote about the final “super-retrospect” we had with the map search project revealing the questions and answers the team came up with. I wrote that communication were the key for our success – Thomas is the reason we communicated well and continued to do so during the project.

If you are remotely intrerested in product development process you reallty should check out his series of blog posts on that subject.

And I am sorry for the poor Star Trek references.

Earlier posts on “Not Even Wrong”

Not Even Wrong – Reality Check III

July 2014
Stockholm, @ the office

I’ve learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel. – Maya Angelou

I thought I’d talk for a while about how our product development process relates to learning and continuous improvement. Before we move on though, I will take this opportunity to hint of the larger master plan that is lurking between the lines of all these scribblings:

“The third fundamental element of the model is that learning, quite like change, happens all the time at all levels. I posit that it’s impossible to create change without creating the opportunity for learning. This learning is the force that takes us towards our desired state, as we cannot get to where we want to be without internalizing and applying this potential for knowledge that we create.
If this is valid, understanding how we learn becomes imperative.”

Indeed. How we learn. It matters. If you agree with my proposal that learning is imperative, it follows that we might do well to investigate how we learn and do our very best to learn like pro’s. I would also like to stress that this is but one of several aspects of learning in an organisation.

Now, the theoretical foundations that I lean on here can be found in the work of people like David A Kolb and Kurt Lewin and the concepts of “Experience Based Learning” or “Experiential Learning”. We will return to them further down the road. What follows here in this post is a more practical example of what this can mean.

To accomplish this I thought I’d let you in on a “post mortem” retrospective that we had just a few days ago. While the team had retrospectives continuously during their time together (one of the few non-negotiable practices as the team chooses their own process), I also see great value in looking back at the whole time period that the team spent together and taking a more “big picture” approach to our work than can be squeezed in during the discover/deliver-phase retrospectives.

During this one-day “super-retro” we went through these steps:

1. Timeline of the time spent together
2. Timeline – Happiness Curve
3. Timeline – Productivity Curve
4. Exercises:

•What does a team need to deliver with quality?
•What does a team need to deliver with speed?
•What does a team need in order to be happy?
•What are the characteristics of a good Team Lead?
•What are the characteristics of a good sponsor?

5. Personal feedback (formalized, written down and delivered orally)
6. Evaluation of the day
7. Beer

We drew a timeline of the whole project, and noted significant events. This helps the team remember their time together and shapes a mutual understanding of what happened. As you know, with memory, every read is a write, so what actually happened is lost forever in the sands of time, but that’s a conversation for another day. Yet, creating a shared mental image of the situation is crucial – even though it can never be “accurate”. This creates a fundament for the conversations that are about to follow. Setting the stage is imperative.

It’s also very important to have a climate in the group where people feel that they can say what is actually on their mind, and not revert to politeness. I mention this because I see general tendencies in several areas to disregard certain set of circumstances that are key factors for success. You can for instance have the greatest set of KPI’s in the world, but that becomes wasteful if decisions are really made by way of power grabs or office politics. And you can have the greatest retrospectives in the world, but if an open culture where people feel that they can speak their mind is not established, you will not get the results you seek. It’s all connected.

Now, we moved on by tracing the general feeling of happiness that the team experienced during the time frame, and drew a curve that clearly demonstrated the emotional “up’s and down’s” of the work. We then did the same exercise with “productivity”. This allowed us to have meaningful conversations about the teams experience.

Then, the Team was asked a set of questions:

  • What does a team need in order to be happy?
  • What does a team need to deliver with quality?
  • What does a team need to deliver with speed?
  • What are the characteristics of a good Team Lead?
  • What are the characteristics of a good sponsor?

The various “aspects” were then listed by the team, and a few rounds of discussion ensued. The next step was to rank their experience during the whole theme work, using the scaling approach inspired by Solution Focus. The Team Lead exercise was designed so that we could have a look at the Team Lead’s idea of himself (Ideal Self) versus the Team’s perception (Real Self). This provided some clues and was valuable feedback for the Team Lead.

Another dimension of this was that even though we were looking for team averages as they graded their experience, we noted when there were significant diversity in the group experience, which led to interesting discussions and insights.

Below you’ll find the question and the answers that the team came up with.

What does a team need in order to be happy?

  • No hidden agendas.
  • Being co-located, preferably in the same room.
  • Agreement regarding how the group makes decisions.
  • Good talk.
  • Defined Roles.
  • Laugh together.
  • Celebrate often.
  • A sense of purpose and progress towards the goal.
  • Understanding and acceptance of diversity in the group.
  • Shared spaces for communication, ideas, progress and checklists.
  • Shared understanding of what it is that group wants to achieve.
  • Shared understanding for the the decisions made by the group and the sponsor.
  • Care about each other as people.

What does a team need to deliver with quality?

  • The necessary time, resources and skill to be able to try different alternatives with and without users, and the time to react to the feedback.
  • Freedom to chose our own methods and tools that work for us in our context.
  • A clear goal.
  • Good people.
  • All the skills necessary in the team, or adjacent to the team
  • Free reigns and focus.
  • Reasonable time frame, time frame set by the team.
  • The sponsor cares about the result – measurements and quality
  • Design towards measurable goal.
  • Stability in the team – not moving people around.
  • Frequent delivery and short feedback-loops.
  • Stability in the environment.

What does a team need to deliver with speed?

  • The right skills for the job.
  • A good environment.
  • No breaks or disruptions during the work.
  • Frequent delivery of value and short feedback loops
  • A team up for the job (team size).
  • No unexpected disruptions during the work.
  • A Team that can collaborate and work together well
  • Trust from the organisation.
  • Focus – one thing at the time.
  • Slack.
  • Deadlines or rather commitments towards a time frame.
  • Small batches of value.
  • Clear goals.
  • Ability to find problems early.
  • A backlog that is properly prioritized.
  • The ability to constantly re-prioritize.

What are the characteristics of a good Team Lead?

  • Facilitates the group.
  • Makes sure that the needs of all group members are met and provides a natural place for each individual.
  • Takes care of the planning.
  • Protects the team from exterior disruptions.
  • Focus on clear goals.
  • Is responsible for the group dynamic, and the development of the group.
  • Makes the team visible in the organisation.
  • Clear take on the user goals – business goals – tech goals triangle.
  • Clear take on the time – quality – resources triangle.
  • Keep the moral of the team high.
  • Makes sure that necessary decisions are made when necessary.
  • Communicates needs, obstacles and progress to the organisation.
  • Passionate about product quality.
  • Motivates.
  • Has a sense of responsibility.
  • Is passionate and committed.

What are the characteristics of a good sponsor?

  • Trust that the Team can deal with the task at hand – no micro management.
  • Sponsor must be able to set clear goals.
  • Sponsor must feel a sense of responsibility for the job, and the goals that they have commissioned.
  • Care about the User Experience.
  • Understand the difference between wanted outcome, measurements, user goals and business goals.
  • Show interest and commitment.
  • Understand the consequences of the prioritization’s that they are asked to make.
  • Be able to make quick decisions and change course if necessary.
  • Be loyal towards their own decisions and prioritization’s.
  • Follow up on progress and achievement of goals.
  • Be clear on what they are commissioning and why, and communicate this to other parts of the organization.
  • Be prepared to re-prioritize and shift focus and allocation of capacity.

Now, what happens if you take these insights, place them on the happiness and productivity curve and create an overlay with the personal feedback?

Interesting stuff, for sure.

Earlier posts on “Not Even Wrong”

Not Even Wrong – Reality Check II

June 2014
Stockholm, Café Italiano

I heard from a former colleague that he uses the Holistic Product Dashboard at his new workplace in Nairobi, Kenya. This excited me, so I decided to ask him a few quick questions.

Here goes:

So I understand that you use the Holistic Product Dashboard in your organisation. This makes me happy. Can you tell us a little bit about what needs of yours that the model meets?

The model helps us thinking in terms of defining what really drives us towards our vision and prioritize our most important value that will help us get there. It therefore helps us sort and prioritize and clean up the list of things we think we should get done.

How did/do you use the model, and what was the result?

We started out by actually thinking about our vision, to see if we could still agree with it. Once we decided on that we started to define our enablers and our vision pillars. 

The vision pillars have been the hardest to define and it has been a good exercise to really think about what is necessary for us to reach our vision. 

We then used the vision pillars to sort all of the ideas that the team already had (and there were many) into the different pillars. It was then quite easy to scrap many of the ideas and prioritize the ones that could stay. 

We then use the “filled out” model when the time comes for us to take on something new and pull the theme that makes most sense right now.

Cool, huh? I like the idea of people in Kenya using the model. It makes me smile.

Earlier posts on “Not Even Wrong”

Not Even Wrong - The Holistic Product Dashboard

June 2014
Stockholm, Papas Deli

One of the most important insights of the new systems theory is that life and cognition are inseparable. The process of knowledge is also the process of self-organization, that is, the process of life.
- Fritjof Capra

Yes, it’s yet another model. I must confess that I revert to blogging about my models when I don’t have any new decent writing – which is actually from the book – to present. I’m currently entrenched in research mode and spend a lot more time reading than writing.

I’d like to talk somewhat about holism by way of an example. The topic of holism will run like a red thread through this here book I’m writing, so I thought it might make some sense to write about something related.

Screen Shot 2014-06-14 at 16.12.31

The first image you see is my attempt towards a holistic dashboard that visualizes an organisations efforts to reach their product vision, and ultimately move the organization to the larger, grander super ultra vision.

The model presents “Vision Pillars” that are answers to the question “what do we mean when we say the best X in the world” (or in what ever terms we chose to express our vision).

Many organisations don’t work towards their vision – even on paper. The reasons for this usually has to do with money, which can be quite frustrating and demotivating for the people involved. In those cases, the vision starts to feel disingenuous after a while, and people begin to wonder if we should perhaps just be true to ourselves and replace the nice sounding vision to something like “make money for shareholders”, or “reach the goal of the most influential member on the management team” or “what the CEO wants”. At least then people get an opportunity to see the direction that the decisions support, and then they don’t have to suffer total confusion each time new announcements are made. This could dampen some frustrations.

The problem is of course that truthfulness and transparency in this area also allow people to assess if they want to spend their work life pursuing this actual vision, when they were recruited believing that they would work towards the pronounced vision. Truthfulness opens up for a “like it or leave” choice. This is probably why we see so much lip service in connection to visions, which is a rather disturbing lack of honesty towards the staff, if done on purpose. Most of the time though, I wouldn’t suspect foul play. If you hear the words “We’re a profit-driven business, after all. Nothing strange about that”, I’d say you’re dealing with someone who has never asked questions such as “What is the purpose of this organisation?” or even “What is the purpose of any organisation?”.

If you spend some time reflecting on such things, you might end up believing, as I do, that we need profit in order to survive. And just as in life, the only point of surviving is so that you we can keep on having fun, keep growing and do some good in the world. Corporations provide economic safety to people so they can feed themselves and their kids and pursue their dreams. In organisations, as in life, the journey is the goal. But I digress.

Suffice it to say, for many of us it’s important to feel that there’s a higher purpose than money. Modern motivational psychology seems to agree with that sentiment. Vision Pillars are in my experience a good way for us to make sure we feel that we’re actually working towards our vision, as we can follow the assumed causality.

Now, most Product Managers live far to the left in the model, in the vision pillar I’ve chosen to call “Most Usable”. This is where features live. Product people love features. For good reason. It’s fun to build new stuff that helps solve people’s problems and make their life easier or more joyous. It’s also very clear that many dive into “feature-by-feature” comparisons with the competition and then somehow think that if we match or excel at a feature level we must be “better” and that this would somehow ensure that we “win”. This places a lot of unhealthy trust in our competition that they get things right, and reduces us to reactive followers in the market place.

So this model is actually in some sense a response to the feature fanatics. Any product have a collection of aspects that all need to be taken into account when developing products. If you build products that are enjoyed online,  as many of us do, the most usable kick ass feature in the world is worth absolutely nothing if the site goes down, or if it’s terribly slow, or if the customers can’t figure out how to use the feature. Furthermore, most products have a core offer and the rest is “just” nice to have add ons. There might be more value in improving on your core value than adding new stuff. The Kano model can be a helpful thinking tool when you assess your product from that perspective. We’ll get back to Kano later.

In this example I have chosen the following vision pillars:

  • Most Usable – solves customers problems.
  • Usability – easy to understand and use.
  • Performance – Uptime, speed etc
  • Look and Feel – visual design, transitions etc
  • Most Accessible – works on all screens

Below the Vision pillars you see cells representing stuff we do in service of the goal the pillars represent. The things we find in these cell are preferably expressed as questions. As in “How can  we help our users achieve X”. A green frame around a cell signifies that this is the question that we’re currently trying to answer. This then, means it’s work in progress, which makes this model a nice companion to a Enterprise Kanban board (see image two)

Above each pillar you see three cells: “Current State”, “Goal 2014” and “How we measure”, together with the possibility to grade our current state and our desired state, inspired by the scaling approach found in Solution Focus. It allows for us to ask “today we grade ourselves as a four, and we’d really like to bump our grade up to a six this year. How can we close the gap between our current state (four) and our desired state (six). What can we do? Any ideas?”. I’ve come across quite a few people who think that this is a very simplistic approach, upon which I reply “thank you”, choosing to hear “easy to understand and use” instead. You would have to prove to me that making this more complicated is in any way helpful.

Above that you see two enablers. The first is “Team, Process, People”, and here we concern ourselves with the development of these three important aspects, as I believe that we need to have an eye on the  long term development of how work works and the development of the people doing the work. It would be rather difficult reaching any grand “best in the world” vision without this investment in continuous improvement and development of people. Taking the long view is key, I believe, and I very much disapprove of short-termism.

The second enabler is “Customer Service”, as I believe that how we help our customers could well be considered a feature of our product. Both these “enablers” could be placed in vision pillars of their own, but I chose to present them this way to explain my position that there’s much worth to be found in thinking about what we need to have in place in order to reach our goals, not just what we have to “build”.

Above these enablers you see the Product Vision and the Organisation Vision.

So, we have now reached the point where we can clearly see how it all fits together. Everyone in the team can see that the current assumption is that IF they work on feature A THEN we can raise our grade from a five to a seven, which means we are “More Usable”, and this takes us closer to our Product Vision, and we assume that by doing that we move closer to our Organisation Vision.

Screen Shot 2014-06-14 at 16.12.46

In image number two you can see how the Holistic Product Dashboard integrates with my proposed organisation structure and the three aspects of what we should do – the trends – what we want to do – the product vision – and what we can do – the kanban board, which illustrates how we keep an eye on our capacity. The green framed work items you see in the WIP column, is the same value options we see in the Holistic Product Dashboard, and they’re also shown as label in the yellow “Plan-Do-Learn” cycles, which is where our cross functional teams work their iterative magic.

Earlier posts on “Not Even Wrong”