A Better Way to Build Products: The Journey Team Model

To consistently build exceptional products, you need the right working model and process. At Soluto, we’ve developed what we call “Journey Teams” — inspired by both the Lean Startup methodology and Spotify engineering culture videos. The name comes from the concept of mapping a user’s journey with a product or service. Our Soluto teams are designed around unique points of the user’s journey. Journey Teams have their core tenets, but let’s look back at a few different models to see how we landed here.

Waterfall

When I started my career as a software engineer, my company operated in a traditional Waterfall model. A Business Analyst would spend months meeting with “the business,” writing and revising a Functional Specification document. This document would often be hundreds of pages long, describing in detail how the software should work. The document would be handed to an engineering manager who would then assign one or more engineers to work on it. As a junior engineer, I enjoyed it because I could spend all my time on what I preferred to focus on — writing code.

But, there are a lot of problems with Waterfall software development. It can take months or years to go from ideation to shipping. Furthermore, the Functional Specification never reflected what the users actually needed. The length of the feedback loop was too long. The team would get the first real user feedback only once the product was fully implemented and shipped to production. And even if the Business Analyst was a genius, a lot could change in the business environment between the time the document was written and the time the engineering team actually shipped the product. The bottom line is that, in the Waterfall model, the product being shipped rarely reflected what the users needed.

Scrum

Companies slowly evolved and became “agile.” Most companies adopted the Scrum methodology when they first moved from Waterfall to Agile software development. Scrum was better for a handful of reasons. Teams focused on developing Minimum Viable Products (MVPs), which got them to production faster. Iterations were shipped more often. Faster implementation and iteration helped ship more of what users really needed because it shortened the feedback loop.

But, Scrum has problems as well. Even though it’s lighter weight than Waterfall, it still comes with quite a bit of process baggage. It requires a Scrum Master to facilitate the Scrum process and sprint ceremonies. You have to plan, prioritize, and estimate (“story point”) weeks worth of work at a time. One common issue teams faced was priority changes or “something urgent” coming up mid-sprint. Sometimes, we would put it in the next sprint and miss an opportunity. Other times, we would take it on and bump other stories to a future sprint.

Another issue we faced in Scrum is the emphasis placed on accurate estimates — something humans are notoriously bad at. We would often push ourselves hard to compensate for underestimating stories. If you’re bad at estimating, as most people are, or you work in an environment where priorities change often and you have to react to “urgent tasks,” this emphasis on sprint commitments can quickly burn a team out.

Kanban

Moving from Scrum to Kanban fixed many of these problems. Kanban is lean, more lightweight than Scrum, and a lot less prescriptive. There are no special roles, sprints, high-stakes estimates, or planning out weeks worth of work at a time. You break stories and tasks down into things that can be completed in 3–4 days. You deploy them to production as soon as they are done.

With Kanban, there are still daily standups, retrospectives, and weekly planning meetings. But teams can react to priority changes at any time, without bureaucracy. A Work In Progress (WIP) limit ensures that you have focus. The goal is to minimize the amount of in-flight work that is not complete. That’s because having one feature 100% done and in production is much better than having two features halfway done.

One secondary benefit of WIP limits is pairing engineers on tasks. This ensures tasks get completed faster and engineers are able to learn from each other, improving quality as a result of the constant peer review. Additionally, the knowledge is better spread out, so that if one engineer goes on vacation, there are others who are deeply familiar with the code.

But using Kanban does not guarantee that you will build exceptional products. Teams can still have constant priority battles. Teams can still be blocked by dependencies. Teams can still be structured wrong. They can be large and have strict roles and hierarchy. And, teams may still not measure themselves objectively.

Journey Teams

Here’s where our Journey Team model takes off. We start with Kanban and add a few key tenets.

Journey Teams are…

…focused on desired outcomes

…autonomous

…small, flat, and cross functional

…feedback and data driven.

Journey Teams are focused on desired outcomes.
It’s important not to create teams around layers in a technology stack like “Database Team,” “Services Team,” “Mobile Team,” or “Web Team.” Journey Teams are not even created around specific products like “Knowledge Base Team” or “CRM Team.” They are created around desired outcomes.

Teams are measured by Key Performance Indicators (KPIs) around those outcomes. For example, if you’re building a Technology Support service, you may have a Journey Team called “Employee Onboarding.” Their mission may be to find, vet, and hire the best possible experts for helping customers with technology support questions. A KPI for this team could be something like “number of experts onboarded this month” or “cost per onboarded expert.” A name, short mission statement, and a KPI — all aligned with a desired outcome for the company — gives the team an important sense of focus and the ability to measure their progress. This focus on KPIs keeps the team from having constant “priority battles” that are common in Scrum or even pure Kanban.

Journey Teams are autonomous.
In the ideal environment, a Journey Team should never be dependent on any team or individual outside of the Journey Team. We consider dependencies to be evil. In the example above, the “Employee Onboarding” team should be able achieve their mission and affect their KPI without dependencies. This takes away excuses. It also gives the team a sense of ownership, empowerment, and inspires a start-up spirit.

Journey Teams are small, flat, and cross functional.
They are usually composed of a product manager, a UX designer, a test engineer, and two to four software engineers. Although one of the engineers is a “tech lead,” there is no reporting hierarchy on the team. An engineer may help with UX. A UX designer may help out with product management tasks. Everyone contributes product ideas. Every engineer works on the full stack — services, web, mobile, etc.

Keeping the team small creates a strong sense of comradery and improves collaboration by keeping the number of communication lines low. Not having a reporting hierarchy and allowing people to play different roles, keeps everyone engaged and takes advantage of everyone’s full potential.

Journey Teams are data and feedback driven.
Rather than making a big assumption, building a feature, then releasing to production without any further feedback, our teams take a different approach. Initially, we build the feature as an experiment and deploy it to a small cohort of users. The team has the ability and freedom to deploy often. The technology to enable a feature for a small cohort of users is critical in this model (you can use Tweek, for example). It’s also important to have the right technologies in place to capture and broadly share data from the experiment (we use tools like MixPanel and Geckoboard).

Once the experimental feature is deployed to a small cohort, the team looks at the data and collects user feedback. Data for the cohort that has the feature is compared to the cohort that does not have the feature (this is known as A/B testing). If the experimental feature proves to be beneficial — for example, it increases the number of qualified experts that are brought on in the “Employee Onboarding” example above — the feature is scaled to all users. The data (quantitative feedback) is augmented by user feedback (qualitative feedback) when appropriate.

If the data or feedback shows that the experimental feature is not beneficial, the team takes those learnings and devises a new experiment. In either case, data and feedback drive what the team works on at every step.

Journey Teams are an effective and rewarding way to build products. Focusing on desired outcomes ensures that we build the right things, rather than simply putting out well designed and engineered features. Establishing autonomy enables us to move extremely fast, since we are never blocked and waiting on others. In terms of structure, our small, flat, and cross-functional teams unleash everyone’s talents, regardless of role or seniority. Finally, remaining focused on data and user feedback enables us to measure the impact we’re making towards real outcomes, rather than vanity metrics like story points.

In this article, I wanted to share my personal experiences with various Product Development processes and give an overview of Journey Teams. We’ll write more on this topic, so check back often. And if you’re interested in joining our team, feel free to check out the job openings at Soluto Nashville and send me a note!