10 tips for success in digital product delivery. Part 2: Product
Second of our three-part blog series exploring key pillars of success in digital product delivery. Here, we talk about Product.Read more
You’ve identified the right product to build. You’ve tackled the four big risks. Now you just need to build the thing. What could go wrong, you ask?
As it turns out, quite a lot. According to a Geneca survey, 75% of IT and business professionals say that their software projects are “always or usually doomed from the start”. This is disheartening. With the breakneck pace of competition and a challenging economic climate, no one can afford to waste time or money on failed product ventures.
To help you overcome these challenges, we have devised a blog series that will focus on three key areas of digital product delivery: people, product, and process. If you’re a product leader, this series will help guide your team to success. If you’re a product team member, these tips will help you bolster your product perspective and become a more effective team member.
Part 1 of our three-part series will focus on the people responsible for product delivery. Let’s get to it.
The “three amigos” model has long been touted as a way of identifying the key individuals that help to define incoming requests without pulling the rest of the team away from their assignments. Traditionally, the three amigos are individuals on the product team who represent business, development, and testing.
The job of the amigos is to clarify new features and tasks prior to those work items reaching the delivery team. Typically, the amigos will discuss the new feature/task, hold a session to define the “definition of done”, and then pass the information along to the product team. This approach helps to encourage collaboration, eliminate confusion, and establish a common vocabulary among the team. The number and nature of the amigos can be adapted to fit your specific business and needs; at Somo, we typically use a “Four amigos” approach which includes product, design, development, and QA.
Often, this concept will naturally evolve into the amigos serving as leaders on the product team. The amigos frequently serve as liaisons between the team and business leadership, and when questions arise among the team they will often turn to the amigos for help. This means the individuals chosen to serve in this role will have an enormous impact on the success of the product team. Choose your amigos carefully and place your trust in them to lead the team to a successful outcome.
The best product teams encourage each other to take risks and do not punish team members who offer a new idea or ask a potentially embarrassing question. This is not opinion; the term is called “psychological safety”, and it is a primary finding of Project Aristotle, Google’s project that answered the question “What makes a team effective?”. Teams with higher psychological safety were found to be less likely to leave Google, more likely to accept diverse ideas from their colleagues, bring in more revenue, and twice as likely to be rated as effective by executives.
So, how can product leaders create this atmosphere? According to behavioral scientist Amy Edmondson, there are three ways leaders and team members can help foster psychological safety among the team:
Frame work as a learning problem, not an execution problem.
Acknowledge your own fallibility.
Model curiosity and ask lots of questions.
Take a moment to reflect on your past and current team experiences with high performing teams. Were team members afraid to contribute their own ideas and ask simple questions? Or were they free to ask lots of questions and speak their mind? More often than not, the latter will be true of the most effective teams. For maximum impact, strive to create an environment that fosters a strong sense of psychological safety.
Much has been said about the need for autonomy in software, which means that teams should be independent and self-governing. This is certainly true, but an often overlooked aspect of autonomy is the structure of the team itself.
Imagine your boss asks you to make sure your co-worker submits his expense reports by the end of the day. No matter how hard you work, if your coworker is preoccupied or unavailable that day you will fail (and likely stress yourself out in the process). This is a common problem faced by teams charged with software execution: they are given a deadline but their destiny is controlled by individuals outside of the team.
To provide true autonomy to your delivery team, first understand the product’s objectives and the major tasks required to achieve those objectives. Then structure your team with the individuals who have the skills required to complete those tasks. For example, if your product is fully dependent on changing an API managed by an overseas team, pull a member of the overseas team to work with the product team to write and test the necessary code. If you are creating a product for lawyers, make an in-house lawyer part of the product team to provide the necessary business expertise and avoid delays. The idea is to ensure your product team is staffed with the core competencies needed to quickly deliver a successful outcome.
Note that this does not mean creating a detailed, comprehensive, waterfall-style task list. To identify dependencies, the Technical Lead and Product Owner can list the major success factors for the product and what skills are needed to achieve them. This should not require a months-long requirements gathering session.
True autonomy is difficult to achieve at scale, but there are a number of large organizations that operate with highly effective autonomous product teams. Spotify is organized into squads of no more than eight people, and each squad is responsible for a discrete aspect of the product. Microsoft defined a taxonomy of nomenclature and then drew a “line of autonomy” that allows for clear recognition of responsibilities between management and product teams. Netflix established its culture from the top down to create a framework that allows product teams to make autonomous decisions. True agility cannot be achieved without autonomy, and each of these organizations created a structure to enable autonomy at scale.
Massimo Bottura is one of the most revered Italian chefs in the world. But if you dropped him into a French kitchen and told him to get to work, he would need some time to adjust to the new environment and learn what tools to use before producing results.
The same is true of software developers. Too often companies shuffle developers onto different teams or add developers to a team that is approaching a deadline (“throwing people at the problem”) and expect immediate results. When deadlines are missed, the team and leadership are frustrated. The reality is that products are inherently different from one another in terms of domain, design, and tech stack. And few product teams will operate in exactly the same way.
Be sensitive to the fact that new teams and team members need time to master their domain and go through the four stages of team development before becoming a high functioning team. There is a balance between allowing team members to become masters of their domain and providing them with new opportunities to learn and grow. Striking the right balance helps keep staff motivation high and ensures your product delivery will be successful.
Execution is just as important as strategy. If strategy is the seed, then execution is the water; the best ideas will not thrive without proper implementation. To maximize your chances of a positive outcome, find the right people and equip them with the environment and tools they need to be successful.
Part 2 of our three-part series will talk about how to focus your time and energy on building a product that has lasting value.