The Feedback Loop: Helping Agile Thrive in a Corporate Setting
Last year, Christopher Lomas, Global Digital Leader at Mercer, published an article detailing the ways in which the Agile methodology can fit into the corporate setting of a big company. His 14-steps towards thriving with Agile acknowledged the realities of working within a corporate environment without compromising on the Agile philosophy.
As a follow-up to this successful post, Chris has delved deeper into the workings of a corporate environment and moved from a focus on Agile to product management in general. Since many of our Usabilla clients know the challenges of integrating a variety of tools and processes into one everyday workflow, we asked Chris if we could share his innovative model with you.
So, that’s exactly what you’ll find below. An in-depth insight into product management in a corporate space and how a solid feedback loop can help you thrive.
Product management in the corporate: Re-loaded (Christopher Lomas)
In February this year, I published my first “Product Management Process Flow” diagram for “Thriving with Agile in a Major Corporate“.
The model has since been put through its paces and I wanted to share the latest best practices with you. I’m not going to go over old ground, but I will take you through some of the changes I’d recommend now, focusing on one colored zone at a time.
I want to be clear, this is not a pure Agile flow, it borrows from lots of different disciplines and models (Design Thinking, Lean Startup, User Centered Design, yes Agile, and Kanban), but it isn’t really about trying to influence you or convince you about the worthiness of any of these. It’s more to say that I think outside of the usefulness of each of those, there are other challenges we face when using them in a corporate setting, and those are the observations I want to focus on here.
1. The Blue Zone: Focus on strategy, more
The Blue Zone is about getting really concrete about the vision before we rush to dive into design and development. We do this on purpose because if we rush to design and development without fully understanding the problem, we will either waste a lot of money or end up doing a lot of rework – or most likely both!
“You need to build a picture of the problem, and fall in love with it!”
Whereas previously we had Strategy & Vision in a single box, we are now expanding that out into a whole section in itself. In Foundational Research, spend time on Market Trends, Competitor Analysis, Data Mining, Client Interviews, and other kinds of secondary research. You need to build a picture of the problem, and fall in love with it!
This first gate (the yellow dot between Foundational Research and the Vision, Strategy & Measures of Success) is about articulating the challenge, injustice or hypothesis you have. What is it? Can you articulate it succinctly in one sentence?
We then go to Vision, Strategy & Measures of success: Can you clearly articulate the vision? What will it look like when you get there?
The strategy should then define how you are going to set about achieving that vision. What are the key themes or pillars that you will need to follow in order to achieve the vision?
Then finally, what are the KPIs or success measures that you will need to measure. In my experience, too few projects set these KPIs upfront, but if you cannot measure it, frankly, your experiment or product is worthless, because you aren’t learning from it, and you won’t know what to tweak or improve once you launch it.
What does success look like? Set some goals or hypotheses to test. Set a number. When the Product Owners pick up your vision, they’ll need to ensure that the right tagging is there to ensure you can, in fact, see the results, so you can dis/prove your hypothesis.
The feedback loop
The feedback loop can be anything that gives you feedback but typically might include doing user or client interviews, observing users reacting to your high-level ideas, role play, generative sessions, workshops, surveys, getting feedback from paper-based prototypes or sharing your ideas with partners. For those who haven’t read the earlier post, we are at this stage validating the question: “Are we designing the right thing?”
Once you have gathered the feedback from users, you will have a bunch of new insights. Don’t be tempted to take them all onboard. Qualify them against your core mission or hypotheses. Does the feedback help you solve the core problem?
Once you have enough feedback from users, and have been through the process of Divergence (adding new ideas) and Convergence (narrowing ideas down to a succinctly defined set of epics) – yes, I am borrowing from the Design Councils’ “Double Diamond” here – then you can get to the final decision gate in the Blue Zone, which is Scope sign off for your Minimum Viable Product (MVP).
Make plenty of mistakes early on and always be geared up for feedback, because if you aren’t learning you are wasting your precious time and resources.
2. The Pink Zone: Make sure you take into account all parts of the feasibility study
If anything in this section has changed, it’s that we have added more areas to consider. In the previous model we covered some great areas to think about, but through failing, we realized there are a bunch more teams you need to be drawing in and getting feedback from in your research spikes, especially in a Corporate setting.
Once you’ve been around these groups, you will want to feed the feedback (learnings) back into your product/MVP scope. Don’t be afraid to say “no” at this stage, otherwise what is the point of doing the feasibility study!
Use the learning to inform your decisions about what to build, otherwise, you will be building something that you get either cannot launch eventually or get hit with a major roadblock or dissatisfaction when you do take it out.
3. The Black Zone: Iterative Solution Design and Testing
Here, we are suggesting more dynamism in the way in which stories are designed, tested and refined. Nonetheless, the ultimate goal is to come out of the Solution Design phase with a clear idea of when certain well-designed features could be developed, so that you can answer that question from your stakeholders: “When will I have it by?” (I’m sure there must be a Dilbert cartoon for this scenario but I couldn’t find one!)
Once the teams have done the Solution Design refinement process (or even during the process, if they can get access frequently) you want to be encouraging testing and feedback. That feedback loop would still be useful (obviously) with real users, but at this stage, you also want to be sure to include your stakeholders – think of all the people in the Feasibility phase that are relevant to see the design/scope increments and also your business stakeholders (or sponsors).
The feedback you gather should be filtered through the lens of (as before): “is this feedback relevant to the hypothesis or problem we are solving?” If so, apply it and incorporate it back into the designs. If not, decide if you want to add it to the backlog, but ignore it for now.
Once the refinement process has taken place, the team should be at the stage whereby they have their prioritized stories, with detailed acceptance criteria, designs and DoD (Definition of Done) all well articulated. You’ll, therefore, be ready to commit these to a sprint, at which point we can be more confident in committing to a likely release date.
4. The Orange Zone: Stay connected and ensure quality
Unless you get feedback on an ongoing basis, you risk building something your customers and stakeholders do not want or need. In the model, the feedback loop is there at the top of the process flow diagram, and comes through regular ‘show and tells’ between the Development team and Product Owners, but also between Product Owners and stakeholders.
Although we haven’t redesigned the Development process, I have, in collaboration with our DevOps teams, thought about what would be worth calling out explicitly. We have therefore added a few more specific considerations in the DevOps or Engineering process.
We still see the benefit of Continuous Development and Continuous Integration (delivering regular working code, at least in 2-week increments), and this leads in to Quality Assurance, in the form of automated acceptance testing, as well as performance and load testing, but also a Security Review (which wasn’t previously explicit).
Finally, we lead into User Acceptance testing. This then leads in to the Feedback loop (now very familiar!) and any new insights (which may be from UX/UI teams saying that the pixels aren’t quite perfect, or simply that a during a demo from the development team, you may find something was interpreted differently to what the Product Owner or Stakeholder had intended, and it can still be corrected before releasing.
5. Green Zone: Launch and measurement
We’re on the home straight, but we’re also only just beginning! When we are ready to launch we have only got to the start line… this is a marathon, not a sprint.
If there is one lesson that I have learned it is: you don’t learn anything until you put real data through your system or product. If you can facilitate real data in a pre-launch/beta environment, do it! Once you’ve learned what you need to in order to have sufficient confidence to go to a larger audience then you can open the taps.
Even after you launch you will learn new things, so make sure these things are feeding back into whichever stage of the process is appropriate, but also make sure that you keep tracking the metrics, and track these against the KPIs that you set in the Blue Zone.
I want to learn more, with you, so if you apply any of this and find better ways of helping teams get products and ideas tested and out to market, please hit me up on Twitter (@calomas), on LinkedIn (ChristopherLomas), or leave a comment below.