I’ve managed huge software projects for Verizon, Honda, Toyota, Mirage Resorts, Disney, General Motors, and many more. Over the years, I’ve found projects deliver more quality and faster when multiple small teams are working on the problem and not just one big team. A small number of folks, along with physical proximity, reduces communication issues and improves team focus. Most problems are solved quickly with the ability to lean over and ask a person sitting nearby for an answer versus emailing them (I’m pretty sure we pick up 25% of our knowledge just overhearing conversations).

But there’s a problem: Small teams become insulated.

Good small product teams become pros in their area of expertise, as they should. But they can also start to think they are the experts in the whole solution, from end to end, not just the one part they are focused on. Teams can lose track of what the stakeholder originally asked for, or, what’s worse, they can lose focus on what the customer really needs.

Let me offer a few recommendations on how to avoid this.

1. Get The Team Behind a One-Way Mirror: Get every member of the team to attend user tests and focus groups. From QA to the Product Owners, every member of the team needs to understand what users want and see them using their software. They will likely find their concerns are not the same as the user’s.
2. Get The Stakeholder to The Demo: Let the team show how tough it is to get the smallest things done well, and let the stakeholders respond if that is the right work to be focused on. If possible, have the business stakeholders (or Product Owners) talk about how the work is performing in the market at the beginning of the demo session. If stakeholders can’t attend demos, be sure key team members at least get to business partner meetings frequently.
3. Big Charts: Make results visible. I’ve found it effective to have screen savers on the monitors in the team area show graphs of year-over-year’s sales (or traffic, conversions, net new customers, etc.). Over time, those key statistics become part of the team’s daily conversations in standups and grooming sessions.
4. Get in a Room together: Workshop, workshop, workshop. A workshop can be a half hour meeting or it can be all week, but get in a room and sketch, whiteboard, use a pile of yellow stickies and kick around ideas, together.
5. Prototype. Then prototype, and do it quickly. Overnight, if possible. Bring designers to the workshop and have them work with the developers to prototype the ideas that are being discussed in the room. The prototype doesn’t have be final code. Mock something up and get it to Kinko’s/Fedex overnight and have them mount the images on huge foam coare boards. Bring the boards in to the workshop the next day. You won’t believe how much energy, clarity, excitement, and alignment these big ‘prototypes’ will incent.

As project leaders, it’s our responsibility to do whatever we have to do to drive understanding, not just in words, but in prototypes, sketches, designs, and maybe even code. Bring your high-performing small teams together, then poke and prod them, arm-in-arm with your stakeholders, until everyone understands where you need to go as a big, integrated, end-to-end unit.