Helping people make better decisions is a big part of my job at Cantina. Applying agile methodologies to deliver a project is always a tough call. One of the more significant questions is whether the client is able to fill the Product Manager role.

At Cantina, I’ve both seen and been a member of high-functioning agile teams. It’s usually a fun and effective way to deliver a successful product to a client. But it requires a full-time commitment from everyone on the team including the client.

That’s a lot to ask. Clients have day jobs that require attention and focus: budgets, competing priorities, organizational changes, planning, resourcing and staffing are just some of the tasks they have on their plate.

Meanwhile, holding designers and developers back is like containing horses at the starting gate. They want to design and code. I’ve seen developers finish working before the team knows what we’re going to build. It rarely ends well. Budget, time, resources, and morale suffer.

There’s a gap between client and team. If designers and developers start working before clients have clarity, it causes confusion. If designers and developers wait for clients, resources are idle. The best solution is to enable the team to be more autonomous. Allowing teams to understand “what is the problem we’re trying to solve?” and develop a range of possible solutions. The client (our product manager) then makes the decision about a solution.

We want our clients to make quick, well-informed, and confident decisions. We help clients do this by grounding and presenting issues and solutions in a broader context.

Reframing an Issue

When we encounter an issue that requires a client’s input and decision, we schedule time to understand the objective. One of the more interesting challenges of agile is that there is usually a high-level goal, but objectives (the way of achieving the goal) are less clear.

So our team takes stock before we know the solution:

1. Gather information
2. Define the objective
3. Ideate solutions
4. Refine

Gather Information

I frequently refer back to Jesse James Garrett’s The Elements of User Experience diagram to get my head in the right place. His expression of UX is foundational and helps to clarify a team’s thinking. Subsequently, we evaluate the issue in terms of:

• Business Requirements: Does the issue stem from a misunderstanding of the business requirements? Is there a flaw in the way things are handled?
• Information Design: Is the issue about communication?
• Information Architecture: Is the issue confusing a user’s understanding of the information space?
• User Interface: Is the issue about a user’s ability to complete a task?

Once we have an understanding of the issue, we look at the technical architecture and technical constraints. Things like “how does the issue impact the technical architecture?” and “does the issue have something to do with the limitations of the technology?” are important questions to ask.

Furthermore, we look at the business constraints: the timeline, major milestones, budget constraints. We look to our clients to guide us there by asking how could this issue impact the timeline?, how will this impact a high-visibility event? and will this issue impact the budget?

Define the Objective

A “my account” button in the upper right corner of a page design prompts the question, “What happens when I click on that button?” What seems like a generally well-understood feature is, suddenly, a full-on crisis. There are technical implications, architectural implications, business requirements and other limitations.

So we step back and ask ”what is the problem we’re trying to solve?” In this case the “my account” is meant to indicate that a user can do something very narrow and specific:

• “Allow users to disable their account”
• “Allow users to change their password”

Ideate Solutions

Solutions can be scratched out on a piece of paper. They don’t need to be high-fidelity, but they do need to do two things: Map to each proposed objective List the understood pros and cons Does it support the goal? Technical impact? Business impact? Project impact?

Making a Decision

So here’s the reality of agile. While there is an emphasis on communication over documentation, we still need to write things down - especially the parts that require decisions. So, what I tend to do, is capture major decisions in a document that we can reference.

1. Background - A statement about the overall goal and how this particular issue was identified.
2. Problem we’re trying to solve - A clear statement that describes the problem in the context of the goal.
3. Proposed Solutions
   • Considerations
   • Data and Content
   • Technical
   • Information Design
   • Information Architecture
   • User Interface
4. Open Questions

Don’t give up on agile just because you can’t be a perfect Product Manager. Lean on your team to share their thinking and proposed solutions. This will allow you to focus on your work, support the team, and guide the direction of the project from a position of confidence.