The Three Pillars of Product Agility, Part 2: Experimentation and Customers
In the first part of this series, we went through the concept of a quarterly North Star to focus teams on outcomes. We also talked about the importance of fast decisions and how that can be cheaper than aiming for more information.
In this second part, we will discuss the importance of reaching out to your clients and how experimentation plays a significant role in discovering opportunities and solutions.
Partner With Customers and Experiment Smart
It’s very powerful to act from a place of not knowing. Stating “I don’t know if this is a real problem for my customer” clears out the air and lowers the pressure of being right.
Working with explicit assumptions is a game changer. It decreases the risks of delivering something unfit, forcing the team to make the right questions until they prove the assumptions are right. Or even assuming the risk of moving forward — knowing they can be wrong.
How many times do teams work on a feature for weeks and engage with the customer just before they launch it? Sometimes, with all the NFRs in place, they are lucky and succeed. Sometimes, it was just a waste of time.
Being customer-centric means partnering with customers when we are assessing their problem until we humbly ask them if something we build eases their pain.
Continuous Discovery With Customers
Customers don’t always know what they want — many times, they are bad at guessing. Focus on their problem instead, capture, and connect to their frustration, wishes, and dreams. Find your representative customers. Create bridges with John, Maria, Peter, or Pauline and get in touch with them for quick feedback on slack, for example. Send them a link to a prototype you are building. Release a beta version to only five customers.
Whatever option you choose, go simple and aim for learning before investing more time in coding. You will be able to become more confident that you are solving a real problem with a fit solution.
The best product teams are committed to regular checkpoints or communications with customers. Good product discovery requires discovering opportunities as well as discovering solutions. It requires doing experimentation from the start and a systematic approach to maintaining the state of inquiry.
Beware of the halo effect, though. Don’t do everything they tell you to. Accessing feedback only means having a more valuable context to make an informed decision. You are not building a feature for John, but for the persona John represents. And look out for bias: yours, customers’ proxies, such as Sales and your customers’ partners.
Build a DevOps Culture
When I was a product owner I felt the frustration of creating a backlog, prioritizing something to build, and geting an answer from the team that it would take one month to reach the hands of customers.
We can be faster and experiment cheaply without coding. But in the end, what really matters is letting the users go through the full experience funnel from the moment they first log in. Grasp the real experience with real performance.
DevOps isn’t a “thing.” It’s a set of principles that lay the fundamental groundwork for a continuous delivery and integration culture. The primary objectives of any DevOps methodology are to speed the time to market, apply incremental improvements in response to the changing environment, and create a more streamlined development process.
Investing in DevOps means to invest in easily deploying a feature. It means to be able to retract fast in case something goes wrong, to toggle features to specific customers only, and to change the way product managers look at fast experimentation. Ultimately, it’s about putting software in the hands of customers effortless, fast and safely.
The time you save on automating the release process is the time you gain to explore new possibilities to delight customers. Or simply making the team happier with a less error-prone process. And one thing leads to the other, right?
Dual Track for a Confident Product Release
In dual-track Agile you start with a discovery track to find out if a product idea is good and if it makes sense to build. Successful findings from the discovery track are added to the backlog of the delivery track.
Discovery work happens concurrently and continuously with development work. Two tracks, but not two teams.
Jeff Patton describes it very well: “Development work focuses on predictability and quality. Discovery work focuses on fast learning and validation. Discovery and development are visualized in two tracks because it’s two kinds of work and two kinds of thinking.”
Discovery is a necessary part of product development. If we’re doing discovery right, we substantially change and kill lots of ideas. While a product manager, designer, and senior engineer may lead and orchestrate discovery, they must involve the whole team in discovery tasks wherever possible.
This means they don’t outsource their research to a centralized research team, they don’t rely on marketing or sales to tell them about customer needs, and they don’t stare at dashboards all day. They leave the building and get some real face-to-face time with the people using their software.
There’s usually more than enough discovery work to do and lots of ways to involve the whole team in doing it. If you feel pressured to shorten discovery work to “feed the beast,” it usually means you’re making decisions to build software before learning enough to be confident.
It’s all discovery and we learn from everything we make; be it a paper prototype, or the next feature in your production software.
This topic is huge. You may want to continue reading what Marty Cagan says on this.
The third part is about change, and the need to set the proper ground to promote effective collaboration and alignment in the team and within the product group. Stay tuned!
