There are many ways to build software, and a multitude of frameworks. From Agile to Scrum (and beyond), processes are massaged and manipulated to suit companies and teams of all sizes. Yet these frameworks don't matter if teams don't understand why they're building what they're building.
At some point in the future, I'll write in more detail about feature driven vs outcome driven product development, but here's a quick summary:
- Feature driven teams chase down feature gaps to win new customers or satisfy existing ones, based on features customers (or, other internal teams) literally ask for.
- Outcome driven teams focus on the hoped outcomes of their customers, the jobs they need to be done. They might deliver features, but they don't start with features.
A slightly different, but complementary approach for outcome driven teams is the "mission team." I was introduced to the concept by Dan Martins, and applied it to product teams I worked with during my time at Zalando. It worked out incredibly well. Happier teams, higher quality, shipped faster.
At a high level, mission teams bring together people from different disciplines to focus on a single, quantifiable business metric. For B2B software companies, this might be a customer referral goal. For consumer software companies, this might be a user retention goal.
Each team pursues a mission for a set period of time, and is entirely focused on a single goal. No competing priorities, no distractions, no helicoptered-in ideas unrelated to the goal. Pure focus.
The team is autonomous, as long as they make progress towards achieving their goal. It's allocated all the resources and talent required to achieve that goal. If data science is a discipline required, a data scientist joins the team. No half-assed, or half-allocated resources. It's all-in or nothing.
If a mission relates to a particular business challenge - like customer support - an expert from that team is embedded within the mission team. There's nothing worse than a product team that hypothesises about solutions without understanding the problem, and surface area of it. Experts also act as advocates for the work the mission team is doing, to internal and external customers.
Dan wrote a fantastic post about mission teams a few years ago, which I recommend reading.