Why it is bad to have a single point of failure in a product and what to do about it.

Every day we solve problems. Some people solve many problems, some few. Most likely, there is a person in your project or team who solves most of the problems. Sometimes it’s a Business Analyst, sometimes it’s a Designer, most often it’s a Product Owner. They know the market, the domain, the customers, the competitors, the features. They know how things should work, and they push their solutions hard. Usually, the team can’t resist and just accepts this situation. Is it good? Can we find better ways? Well, we’ll have to have quite a lengthy journey to find out.

Setting the Stage

Imagine, you have a new feature in the backlog. At this point, we have several potential scenarios, each with with a different level of harm:

Leave everything up to the developer. Discuss the user story just before implementation, come up with a solution and do no specs. Make all decisions on the fly. Discuss the user story just before implementation, come up with a solution and do the specs. Assign the user story to a Product Owner, let him come up with a solution and have him do the specs. Have UX phase, brainstorm a solution and create the specs just in time, before development starts.

You can see that some of the scenarios are good, some are bad, and a few of them are just horrible.

To create a perfect solution, we should answer the three simple questions: When? Who? How? Well, the most important question is Why? We’ll assume it’s already been answered.

When?

Each story has its own life-cycle. It is born, it lives and then dies. There are three important moments in the life of a feature:

Someone has a good idea, and a feature is created in the backlog. Development starts. User story is released to production.

When is it a good time to have the complete solution? Obviously, not right after the story is created, as things change, and it may happen that this user story is no longer required. It may just be deleted from the backlog in the future. Somewhere in the middle when we have more data? Maybe, but still not perfect. The perfect match is when we have the solution right before development is about to start.

In this case, the solution is fresh and shiny. Everyone in charge does remember why things should work exactly the way described in the specs. It is certain that the user story will actually be implemented, so the solution and the time spent on it will not be thrown away.

If a feature looks very simple, the UX phase can start about one week before the implementation. If a feature is complex, several months may be a good time frame.

Who?

Many teams rely on the Product Owner, Business Analyst, etc., and expect solutions and specs from them. A team doesn’t care about the solution, but does care about the completeness of the specification. Sometimes this works — but in most cases, it doesn't.

Some teams rely on communication and do not create specs at all. They brainstorm a solution on the fly and then jump to coding. Sometimes this works— but in most cases... well, you get it.

Some clever teams rely on a group of people that consists of developers, testers, designers, and product owners who brainstorm the solution, find the best one, then iterate and delegate writing specs to the product owner. And these teams rock.

Why are the first two cases bad?

The Hero

Yes, Product Owner is responsible for the product. Yes, he knows a lot. Yes, he can solve problems. And, yes, you expect too much of him. It is quite unusual to expect the best solution from a single person. It is always better to have a small group of people with various skills, various backgrounds, and various focuses to find a great solution.

The Product Owner can brainstorm everything alone and write all the specifications. He can haul the product alone. As a result, he would be a single point of failure... while there are many other buses in the streets.

The communication would be one-way, without much collaboration. In such an environment, the Product Owner would tend to ignore the opinions of other team members, since they do not participate in problem solving. If you don’t participate, why the freaking hell should I care about your opinion?

Knowledge sharing would be zero. The Product Owner is a domain expert, he knows a lot. But the team gets zilch from his experience. There are no discussions, no collaboration, no two-way communication flows.

I used to be such a person. It was not good for the company.

Product Owner’s Rule #1: Don’t do everything alone

The Rush

Got a real problem? Get together, brainstorm it quickly, get shit done, and kick it out of the door. Sounds good? Hell, no. The good thing is that you don’t waste time and rush straight ahead. The bad thing is that the solution would be great rarely, good sometimes, and in most cases just average.

In "the rush" mode you tend to cut corners, take the first acceptable solution, and go for it. There are situations when this is good. In an emergency case, this is a viable strategy — but in the long run, it will not work. Rush mode is very dangerous. You might even be proud of it and call it “Agile”, but it is not.



— OK, the quick add feature. Who’s got any ideas?

— Well, let’s just put up the Add Task link . You click it and see the input field with the Name label and Save button. You add one task and see the input field again, so you can add many tasks quickly.

— Great! Let’s do that right away.



Maybe this is somewhat stretched, but in reality I saw very similar situations (and did very similar things myself!).

Product Owner’s Rule #2: No rush

The Team

I bet you expect a viable solution now. Here is the algorithm:

Brainstorm every feature in a small group of 4-7 people. Invite developers, invite testers, invite designers, invite product specialists. Invite everyone who has diverse skills and can contribute to a discussion. Think. Talk. Draw sketches. Learn some techniques like Design Studio. Actually use them. Draw sketches. Build trust. Support honesty. Ban sarcasm. People should trust one another, or you will have a bunch of gamblers instead of a team. Don’t be afraid to criticize bad ideas. The people who can’t stand some reasonable criticism should leave. Repeat. Several times for each feature. Mix people. Invite new people. Eventually, several teams will emerge: the teams that can solve problems without you. Find people that can lead features and be responsible for the solutions. Let them lead UX sessions and play the Feature Owner role. Create beautiful specifications (this is where I really suck).

It took me 7 years to come up with this solution. It works.

Product Owner’s Rule #3: Spread the knowledge, use diversity, delegate

How?

The “how” question is very broad. How to form teams? How to find solutions? How to evaluate them? How to document solutions? I’m going to just scratch the surface here.

Creative processes are hard to structure and hard to estimate. In general you don’t know when you’ll have a great solution. It may take several days or several years.

Each Feature Team has its own UX phase. Some people like to think alone, have decent preparations and then share ideas. Some people like to brainstorm things ad-hoc. Some like to sketch a lot. Some like to create paper prototypes. In general, it does not matter which practices and tools people use. The must-have rules are:

Diversity. Team should consist of diverse people. Iterations. First solution is not always the best. Neither the second, nor third. Feedback. Team should share potential solutions with other people and with customers if possible (and listen to their feedback).

There are many practices and tools you can try. I’ll just list some of them here:

Design Studio. In a nutshell, you have a group of people. These people can split into teams or work alone. They have limited time to sketch the solution and then present the solution to everyone. Solutions are criticized. Then, they iterate based on the feedback and sketch again. We’ve been using this approach with good results. Yes, it is time consuming. However, time is not important when you want to spread knowledge. So use Design Studio in the early stages of people's involvement in the solution phase.

Sketches. The ultimate tool to brainstorm, explain, evaluate, and present ideas. The main advice I can give is: hide your “OMG I can’t draw!” fear and sketch a lot. You will get better eventually. Sketch + speech is so powerful, so fast, and so cool. You can iterate very quickly, try a dozen approaches, and skip bad solutions.

Critique. Do it. Express your opinion openly and politely. Don’t hesitate to upset someone. You solve problems here. Bad solutions should be thrown away. If you’re afraid to say something critical about your boss’s solution — it’s a bad sign. Fuck the common brainstorming rule about ideas and critique separation. This is only needed if you don’t trust each other. Trust gives you freedom of speech. Use it appropriately.

Diversity. It really works. There are many proofs and observations on how diverse teams outperform experts and solid “think-alike” teams. Try it.

Paper prototypes. Not as fast as sketches, but still good. With paper prototypes you can evaluate flows and find bottlenecks. It’s easy to grab them and ask some teammates to try something. You can even shoot a video and share it with people.

Dynamic Prototypes. HTML+Javascript works best for such prototypes in most cases IMHO. However, there are many other tools that do provide decent solutions. We’ve had a somewhat mixed experience with live prototypes. In some cases they did work, and we got valuable feedback. In most cases, we spent too much time on them, and feedback was not so useful. Prototypes work great to prove some limited ideas about a solution, but they don’t work as full-blown usability tests.

Usability Tests. We do them on a real application now. About 10 tests give a ton of feedback.

Product Owner’s Rule #4: Learn and try new things

The output of the UX phase is quite simple: feature specification. How to create beautiful specifications? We’ll talk about that in the next article with an intriguing title “Visual Specifications”.