How to stop useless arguments, make better decisions and have

Move way faster! This simple technique will improve your team's decision making, execution, and team communication

The reason you need a method to do task analysis

“Analyzing my task using this tool forced me to think about various pitfalls I will meet along the way, and make sure I will avoid them entirely instead of finding my way out of them.”

At Soluto we work in teams that include at least a developer, UX designer, and product manager.
Once a task is selected from the team’s backlog, the first step is Analysis. The problem was that the output of the analysis phase wasn’t properly defined, so we didn’t know what’s expected of us during this phase. We found ourselves in all sorts of unwanted situations. Examples of such situations:

• Developers slipped from the analysis phase into implementation mode without pausing for a moment to think about their solution.
• Misalignment (=A LOT of discussions and arguments) between the person defining the task (usually the PM), and the person working on it (usually DEV or UX). This can be around the timeline, chosen solution, who are the users, implementation effort, price, etc…
  And since you asked - No, a more detailed specification document didn’t solve this problem.
  It didn’t solve the fact that there will always be a gap between the person writing the spec and the person working on the task, there’s always a grey area.
• We found ourselves repeating questions when someone shared how they plan to move forward with a task: Did you talk with X? Will it require a lot of maintenance? What other solutions have you thought about? How does Google/Netflix/Facebook/etc. solve this?
  Repeating questions isn’t necessarily a bad thing, but it’s a good sign you can automate things, identify issues earlier, and waste less time.
• Technical tasks for which the PM (that’s me) knew less than the developer working on the task. While they worked together to define the task it didn’t make sense to waste this time, the DEV could’ve moved faster without the PM getting in her way.
• Team member made technical decisions, which they only later realized affected the UX of the product, without involving the team’s UX and PM.
• Analysis of tasks dragged on and on, since there was no defined end.

Our ideal solution

We wanted a solution that would:

1. Empower the person taking the task (place control where the knowledge is).
2. Increase the likelihood of us shipping valuable features to our users and business, without wasting time effort.
3. Align us around what we want to accomplish and how everyone (=users/company/team) will benefit from it.
4. The solution must not slow us down.

Since we believe that people should own and be responsible for their work, we came up with a simple technique to formulate the output of the analysis phase.

🥁 Presenting the Taking a Task (or Analysis Output) technique 👏🏼

The output of the analysis phase should be a discussion (written/f2f/other) that covers the points below, the owner of the task should arrive at the discussion at least with an opinion (and reasoning behind it) for the points below:

1. What is the problem we’re solving?
2. Who are we solving it for? Who’s the target audience?
3. What are the main factors in judging the solution?
4. What solutions did you think about and which one do you recommend and why? (we expect people to have an opinion on what’s the best next step).

If this adds bureaucracy, or slows you down it’s missing the point.

Example

What is the problem we’re solving?

As part of our effort to enable teams to release experiences quickly and in high quality we believe that teams should get frequent and timely feedback of their features performance.

The scope of this task is to focus on the challenge of making sure teams have gotten logging and alerting capabilities out of the box for features they release.

We’re hoping to accomplish this in about a week.

Who are we solving it for?

Teams in the company that contribute features to our Web Platform, specifically for DEVs of these teams.

What are the main factors in judging the solution?

Based on research and interviews we did, we believe the most important factors for providing teams with logs and alerts are:

1. Integration with other tools
2. Integration with Asurion SSO.
3. Security considerations
4. Low maintenance

Compare at least 2 solutions (and state your preference!)

Based on the above we compared two possible solutions (see table below), and think that the best way forward is Solution A, because…

Open the discussion

“What do you think? Am I on the right track? Did I miss anything?”

Notice how this simple breakdown allows us to frame our discussions and arguments to specific areas of the proposed solution.

Side effects

We’ve been using this technique in a number of teams for quite a while now and the reactions are pretty positive.

Besides improved planning, this also improved team communication and documentation.
People had more insight into how their teammates are planning to solve an issue, and there is documentation for our decisions which we can reference later when we think “why the hell did we go with this solution?!”

This method established a team terminology, which provided developers, designers and PMs with the language to comment on tasks outside of their role.
i.e. — “I don’t think the main factor in the logging solution is X, I think making it easy to implement is more important.” OR “What’s the reason you think these are the top factors?”

Want to try this? Here’s a template you can use.

Would be happy to hear your thoughts about this.