10 Journey Team Best Practices

Great product teams need the right working model. We’ve found that small, empowered teams have the ability to make the biggest difference — we call them Journey Teams. At Soluto Nashville, we have over a dozen of these teams, all operating with a slightly different approach. But they all share some commonalities. We consider these to be best practices for working in this model.

1. A clear team goal

A clear goal gives the team a desired outcome to work toward, and it provides focus. The desired outcome rallies the team and helps with prioritization every week. Focus ensures that the team’s energy is channeled properly to achieve the desired outcome and avoid distractions.

Think about holding out a magnifying glass on a bright summer day. You want to channel that energy to burn straight through the objective in sight.

Alignment around goals is so important that our teams are named after them — Employee Onboarding, Partner Enablement, Rich Session, Relevant Content, etc. Occasionally we’ll get more specific and use longer versions of team names, like “Finding the best employees” and “Launching new partners faster.”

2. KPIs aligned with the team goal

Data is better than opinion. Key Performance Indicators (KPIs) are metrics that allow teams to baseline and measure progress towards their goal. They ultimately tell the story of whether a team is successful or not. For example, a KPI for our Rich Session team may be the percentage of support sessions that take place in a rich channel (more than just telephony).

3. Autonomy to achieve the team goal

A team should be able to achieve their goal without dependencies on other teams or individuals. All members are fully allocated to the team and together they have the necessary skills to affect their KPIs. This helps to inspire and empower the team, since they are in control of their own destiny. The feeling is similar to that of a startup.

Dependencies introduce costly hand-offs that slow teams down and should be avoided. When there are dependencies, such as when a team needs a modification to a software component that’s owned by a different team, we encourage teams to enable others to modify their components with some review.

4. Weekly planning meeting resulting in specific goals

To ensure the team has a clear path for the week and is empowered to make measurable progress, it’s important to have a brief planning session at the start of every week. We call these “calibration meetings” because ideation and planning are ongoing activities. The purpose of this meeting is to prioritize work and commit to weekly goals.

Features are broken up into cards that can be delivered in less than 3-4 days and added to the Kanban board. To ensure that each card delivers product value, it is best to vertically slice features. A Work-In-Progress (WIP) limit ensures that teams are focused. A good rule of thumb is that a team with 3 engineers should not be developing more than one or two features at the same time. That’s because one fully done feature, that’s deployed to production, is a lot more valuable than many half done features that are in flight.

Each Monday, teams should ask themselves, “What are we going to get done this week that we’ll feel good about?” The outcome of a weekly calibration meeting is: one or more specific weekly goals reflected on the Kanban board as cards. The team then works to move the cards to “Done” by the end of the week, holding each other accountable.

Weekly goals are a great way for the team to keep their intensity level high in order to make amazing progress.

5. Daily standup meeting

Every morning, teams should sync up in person (5–15 minutes) to review the Kanban board and ensure everyone’s on the same page.

A common format is:

• What was done on the task yesterday?
• What will be done today?
• Are there any blockers?

Although there is nothing wrong with every team member giving an update individually, it is more important to update progress on the team’s most important tasks — which should all be reflected on the Kanban board as cards. Visualizing cards, workflow, and progress on a Kanban board is a proven way to improve productivity.

6. Bi-weekly retrospective meeting focused on continuous improvement

Every two weeks, the team should meet to discuss how they can get better in the interest of continuous improvement. It’s important for this to be a dedicated, recurring meeting with a singular focus. This encourages team members to come into the discussion with the right mindset and be open and direct about how to improve as a team.

Most retrospective formats have four parts:

• What went well in the past two weeks?
• What didn’t go well in the past two weeks?
• What are the action items to help us get better?
• Review the previous retrospective’s action items to make sure they were addressed

Without this type of meeting, improvement is difficult to come by. And if you’re not making a conscious effort to improve, you’re getting worse.

7. Write a short pre-spec to get to a shared understanding

Before starting work on any non-trivial feature, the team should get together to discuss the objective of the feature, how it will work, and how to measure success. It’s important to write this down. It can be in Jira, Confluence, Google Docs, etc. The tool is not as important as making sure the document is easily shareable. The act of discussing and writing it down forces the team to be precise and have the clarity of thought that’s necessary to build software. The goal is to get to a shared understanding of what they want to achieve. A side benefit is that other teams and individuals can easily learn what’s being built by referencing the one-pager.

When a feature is conceived, the team first comes up with a hypothesis. Hypothesize and test is the essence of the scientific method. Its application is one of the central tenets of the lean startup methodology. A hypothesis for our Session Quality team could be something like “Moving the 5 star survey from a standalone web page into our mobile app will increase take rate.” In this example, the team would enable this feature for a cohort and see if the take rate KPI increased compared to the control group.

A common format for a pre-spec is less than one page and includes these sections:

• Hypothesis
• High-level overview (can be in User Story format)
• Description of how the feature will work (can be in Acceptance Criteria format)
• Description of how success will be measured (what analytics events need to be sent and what data will be reviewed)

Without writing it down, it’s easy for people to walk away with different or ambiguous understandings of what will be built. The pre-spec can be a living document and it can include links to the UX design and technical design.

8. Work collaboratively

UX designers work very closely with product managers to design how each feature will work. They spend time on the same whiteboard or computer creating wireframes or high-fidelity prototypes. They frequently run their designs by the engineers to get feedback on design and implementation complexity.

Engineers regularly solicit feedback from teammates as they develop. They discuss technical challenges with their fellow engineers and pair on code. They demonstrate functionality early and often to get feedback from UX designers and product managers.

All this is enabled by the product manager, UX designer, and engineers sitting closely together. Team members are committed to providing psychological safety and roughly equal speaking time for all.

9. Create a light technical design before writing code

For any non-trivial feature, the engineers think and talk through the technical design before writing code. The technical design can consist of one or more diagrams like class diagrams, sequence diagrams, flowcharts, etc. These can be drawn on a whiteboard, Confluence, or any other tool. Don’t worry too much about the format or tool. What matters is talking through the technical design before writing a significant amount of code.

We find that doing this has many benefits. First, a better technical solution is produced because multiple engineers contribute ideas. Second, it’s a learning opportunity for less experienced engineers. And lastly, it ensures that there are no lengthy design discussions during code review that cause costly refactoring and frustrations.

10. Collect and analyze data and user feedback for every feature

Teams collect and analyze data and user feedback for every feature. Analytics are built in by default. This is usually in the form of events going to an analytics platform, like Mixpanel.

The team analyzes how much the feature is being used as well as whether it is affecting their KPIs. Product managers and UX designers collect feedback from users through interviews and surveys. User feedback (qualitative) complements the analytics data (quantitative). Data and user feedback tell the team whether a feature is successful or not, and that drives what the team works on next.

Sometimes the data and feedback are not positive. And that’s okay. Teams are encouraged to experiment and should not be afraid to fail. Leadership encourages taking risks and failing fast. What’s important is that the team learns something every time and moves the KPIs in the right direction in the long run.

Summary

The practices mentioned above have been developed over years of trial and error by our Soluto Nashville teams. Like all organizations, ours is unique in team structure, culture, and product goals. So we recognize these practices are not a one-size-fits-all solution. But we encourage all teams to take the plunge and strive toward working in the Journey Team model.

If you’re interested in joining our team, feel free to check out the job openings at Soluto Nashville and send me a note!