WHY is it important to engage stakeholders to determine WHAT our KPIs should be?
I have found that a cleaner way to determine our KPIs and ultimately WHAT our product should be is the Google design sprint. We engage our colleagues from different functions to get their take on KPIs, success metrics, etc. The goal isn’t just launching a product in the market BUT it is to finally get the users to use it and reach our desired outcomes. In order to get a SOLID base for your MVP, you need a design sprint so that all the players involved are aligned.
HOW do we engage stakeholders in design product experiments?
- The key players are product manager and UX (i.e. user experience).
- The product manager can come up with draft KPIs and ideas for the product to begin the conversation.
- The UX designer is key. We use MIRO but there are ton of
collaboration tools out there with which people can share their
thoughts.
- As part of planning, you need to determine the various functions, that need to be involved. The usual suspects are marketing, sales, customer support, partner PMs, lead engineers. But it all depends on the initiative. For instance, one of the initiatives were heavily based on legal and privacy. So, they had to be part of the design sprint.
- If your initiative is technical in nature (eg: infrastructure upgrade, API design) then it is possible that you have solution architects in your discovery.
- Typically, a design sprint (as advised by Google) lasts 5 days. But,
few things might not make it possible to be done within 5 days. Here has
been my experience -
- We live in a global world. So we might just get 2-3 hours a day for the design sprint. We could do the design sprint in-person or virtually. It might take you 2 weeks or so depending on how you go about it.
- When everyone puts their thoughts on either a whiteboard or a MIRO board, then you start building a more realistic picture of what is possible. Especially when it comes to success metrics and KPIs, we start having valuable discussions and it is not an arbitrary number that you have as a goal. For example, we wouldn’t set 3% growth as our goal without getting together as a group and knowing the pros-and-cons.
- In case of healthcare, I had to work with my research team as well to get some facts to support my design sprint. It is of course possible for other domains to need that extra research for the design sprint.
- We did an interesting exercise in which each of us designed what we were expecting from the website. We sought inspiration from different websites like wayfair, amazon etc and came up with our versions. This was a very useful to our UX designer to understand what was intuitive to users.
- Exposing developers especially to the thinking of the marketing, legal, sales etc. stakeholders helps them develop solutions that are usable.
Outcome of a design sprint
When I conducted my 1st design sprint, I was amazed at the speed at which we got to the prototype. Finally, we got to build a prototype, approved by different functions. It accelerated the speed at which we got feedback from the customers.
Final Thoughts
I love the design sprint because it promotes a growth-mindset among the team members. It is also a fun exercise because you don’t get to design websites everyday. Ultimately, a website or a mobile app will be used by multiple users. This sets us up for success! When I did the discovery for an API design product, then it is hard to visualize because you might not have a UX but you can certainly use tools like MIRO or Confluence etc to workshop the design with the stakeholders. So, when we design together as a team, we also get diverse perspectives from many people.