I often get asked and reflect on what makes a high-performance team. How to nurture a product team to a high performing level? And what does it really mean in pragmatic terms?
With a continual-learning mindset in the frame of the last 20+ years in the product management space, I've found that the answer is often quite simple. To me, the key is to simply build and empower a team to develop products that customers value (a lot!!!).
There are often differences in how organisations with high-performing teams develop or manage products that customers value highly and generate revenue for the business. The variances are many and extend from organisational design, innovation practices, leadership style, team structure, cultural principles, and empowerment, to product development, lifecycle management processes, and product discovery techniques. As you can see, there are many factors at play that can influence whether a team is high-performing or not.
Today's article aims to summarise some of the key learnings and our top areas of focus for building a high-performing product team to drive growth.
This includes asking the following 4 key questions about your organisation's enablers for developing and empowering high-performing product teams:
Ask yourself the question - how is your organisation designed to foster innovation?
Organisations with high-performing product teams usually have a fast-paced innovation process and apply lean practices and decision-making including different funding approaches from product discovery to delivery for new product development.
My experience has found that large enterprises often introduce faster-paced innovation practices relative to their existing business as usual practices but more often still apply some level of corporate administration that can slow things down (a lot) or add a lot of overhead in terms of processes, approvals, and the like.
Start-ups often have very fast innovation practices and are mainly focused on one main idea with various branches to focus on with reduced overhead of processes, approvals, and the like.
Building a fast-paced innovation process with lean practices requires organisations to change how they develop their innovation strategy including the end-to-end investment decision and implementation process.
Often developing new products is mixed up with how existing products are managed and this has been proven to slow things down in terms of the product's performance metrics assessments, the investment decision process, and delivery processes.
When you manage products that are in the market this should follow modern product lifecycle management processes including how they are monitored against their key performance areas and drivers of product health. However, for new products, this should follow suitable adapted decision-making/investment processes and must include experimentation and iteration starting from validating a lean canvas and iterating key assumptions with the ultimate objective being to develop a new profitable business model and solve customer problems simply and intuitively.
The most common way of doing this is through incremental funding and decision making where each round of decision making and funding has specific objectives as to how product teams show progress for new ideas being tested, validated, and iterated. The initial funding and or enablement allows Product teams and leaders to build the information needed to see if the product has the potential to achieve the business objectives or the business model fast and continuously. This allows for the ability for the product solution to be validated – does it solve a customer problem, and will the customer pay for it. It also allows for the business model to be validated and to what degree.
Given the early phases of an innovation process are focused on market validation, organisations can achieve market validation objectives quickly with minimal funding if they are not slowed down or halted via traditional investment decision processes.
As product ideas obtain more validation, organisation can make larger funding decisions to achieve product-market fit and scale the product accordingly.
More often I have been involved in large organisations that have developed fast-paced innovation processes but at the same time introduce or pivot and require traditional product investment processes to be followed. This often results in a myriad of overhead processes, extensive stakeholder engagement, and approvals, and slows down the process significantly.
Traditional product investment decisions often require a detailed and approved business case where teams must complete a very detailed case and forecast to justify the proposed product investment with 5+ year projections on the total investment required and the revenue and profits as a result.
In reality, in the early to mid-stages of the innovation process, product teams will not have all the data to substantiate the traditional business case, and often because of this, decisions can be made to stop or slow down on progressing new ideas and products and as a result, the new idea or products gets all mixed up and watered down in the business-as-usual investment process.
In my experience, it is no surprise that product teams and senior leaders know this, but unfortunately, it’s a ritual that everyone follows and if challenged does not necessarily win, and as a result, the process slows things down and takes away from the momentum of fostering and enabling true innovation practices. It can often mean products in their early phases of innovation don’t get money or go too far….or can miss the boat or the momentum needed to get off the ground.
If your organisation does have an innovation process I would highly recommend it sits outside of the normal investment decision-making process, it needs to be carved out and have its own set of funds allocated to it with its own set of suitable agile practices that really enable and foster a fast dynamic innovation process.
This will truly enable teams to test and build/iterate new products or fail these and move on to the next opportunity quickly. Don’t make it part of the big business-as-usual operating machine in the early phases of investment and introduction.
Ask yourself the question - how is your organisation designed around the product delivery process? Does it truly foster an approach of being outcome focussed and empowering?
The reality is that often companies still follow some level of waterfall delivery and its associated practices. Whilst they may have chosen components of agile it may not be part of their core DNA.
For example, do any of these scenarios apply or resonate with you? Your organisation claims to be agile because they have embraced some of these tools or methodologies.
What about the following?
What I have learned is that most high-performing product teams are very clear on the business objectives of their product and have total ownership and responsibility to achieve this. The team defines what progress means and how it is measured.
Their measures include but are not limited to:
The actual product delivery teams agree on what progress means for them, and they make sure they are measuring it.
Another consideration is that often the 'documented roadmap' that is focused on an array of features is not always validated and can be delivered over a long period of time. This at times can result in the focus moving away from the problem it’s trying to solve and people falling in love more with the solution which should not be the number one objective. Coupled with slower or longer delivery lead times that 'documented roadmap' can slowly become a negative vehicle resulting in teams and stakeholders losing morale or faith especially if the product or some of the solution fails in early iterations.
For high-performing products team shift the focus to
High-performing product teams understand and follow the concept of continuous delivery. This provides a continual flow of releases with increased functionality which allows for a more sustainable and scalable build with continuous validation with customers/users. As a result, it reduces risks and time to market and increases product success opportunities. It also ensures that customer feedback is captured continually along the way which results in feeding the backlog and customers asking for more. This is a win-win in most cases when compared to the traditional approach.
Unlike the continuous delivery approach the traditional waterfall method does tend to present more risk before starting the journey of realising value – this is because it takes longer to deliver, it adds more cost as you are building a lot more and it may deliver a solution or parts of a solution which may not be truly valuable or needed. The traditional approach follows a process of capturing very detailed requirements around the full stack of the customer value proposition and completing the full-blown business case. This then gets the tick of approval which drives the development process and, in many cases, takes longer to deliver. Add to the mix lots of documentation and numerous stakeholder approval forums along the way, and less customer validation prior to launch can often result in launching a product/ solution with a whole suite of features that is not necessarily needed or as highly valued as expected and may not solve the customer problem. This ultimately impacts the promised return on investment as part of the business case. Bottom line – test, start small and build on that means faster delivery, less cost before failing or build more as you get more validation and more return.
High-performing teams are also very passionate and able in product discovery methods and creating user prototypes at all fidelity levels which are tested frequently. Its part of their DNA to regularly conduct customer interviews and document and share learnings and link the outcomes to their backlog which is prioritised regularly.
Traditional methods often result in teams waiting for approval of funding to run a customer test and tend to focus on validating a roadmap that is already defined.
High-performing teams understand that continual customer learning is about learning on a continual basis with relevant insights and not about proving or disproving a roadmap.
Organisations need to ensure their product team culture is designed and has a set of principles to give them the outcomes they require and can be implemented and mentored across the team.
To enable your team to work optimally here are a few common product principles for high-performing teams for consideration:
About Skyjed
Skyjed is an all-in-one product lifecycle management and governance SaaS platform designed to help Product Managers drive growth.