Client A: I really wish your product had this. Our business is changing and we kind of need this feature soon.
Client B: I think every one of our competitors has the same problem. It would really help if we had this feature.
A few months later, both clients jump. Everyone is in a panic to find out why, but if we're honest with ourselves, we own part of the blame here. Our clients told us their pain, and instead of doing something about it, we chose to do nothing.
What could we have done instead?
We could have started engagements with each of the clients independently. Requirements gathering and planning will result in custom solutions that would have made clients really happy. However, can we say other clients belonging to our colleagues aren't feeling the same pain? And if so, doesn't it seem inefficient if we were to open a custom engagement with each and every one of them?
My answer is: Of course it's inefficient, and pattern recogntion within services teams can really help in scenarios like this.
Pattern recognition is:
- Collating problems from multiple sources: clients, competitors, market, and even internal to our own organizations
- Defining the commonality amongst all instances of those problems
- Finding a common solution (or solutions) that would solve for those commonalities
The process for pattern recognition is so simple, there really is no excuse to not try it out in any organization. If that's the case, however, then why do the companies I work with seem so surprised at the novelty of the idea?
Well, it may be because it takes effort. Effort in communication. Effort in reaching out. Effort in sitting down and analyzing as a group. Effort in working with product teams to turn solutions into reality. We are so busy in our own worlds, serving our clients, that we become myopic to the bigger problems that are common to so many of our stakeholders. Take the effort to pause, take a breather, and actively participate in pattern recognition so our teams and products can grow.
How can we get started in pattern recognition? I break down pattern recogntion into three separate activities that build on each other:
Hold Daily Scrums to Encourage Objective Sharing
Unlike scrums for dev teams, I focus service team scrums on not on the exact tasks we are trying to accomplish today but specific objectives we are attacking and the results we are expecting to see at the end of the day. I find that when I declare an objective, it becomes very much relatable for a colleague who is also working on something similar. When a shared objective is identified by multiple colleagues, then we should encourage the team to discuss the challenges they faced or are anticipating for the day. Asking "What are you planning to do today to anticipate any problems" is a great starting question, because it does two things: It gives license to the colleague to talk about their concerns, and it allows the group to vet and provide feedback on the approach they are planning to take to address those concerns.
These scrums tend to address short-term objectives because there's so much focus on the results of that day. However, encouraging colleagues to break out into a side discussion after the scrum may result in the surfacing of larger problems, which leads to:
Maintain a Patterns Parking Lot
Pattern recognition isn't done by one person alone. Over time, as more members of the team embark on their own pattern recognition, the list of problematic patterns start to surface. While the urgent patterns are going to be dealt with on an ad-hoc basis, what we'll find is that the majority of our pattern recognized problems are highly important and strategic, but not urgent.
Resist the urge to say "we'll deal with this later". Document the pattern and enter it into a parking lot that will be reviewed by the team during the Monthly Pattern Showdown (See Below). I ask the team to document every issue with five pieces of mandatory information designed to help us focus on how problems affect our clients and other stakeholders:
- What type of problem is this? - Is this an anticipatory problem or are we reacting to something that is not working quite right?
- Who is currently affected? - Is the market affected, a group of clients, internal teams, or a combination of the three?
- Who has the potential to be affected if nothing is done? - Do the affects broaden to other stakeholders if we do nothing?
- Who can benefit if this is fixed? - Who else other than those affected right now will cheer if we address this?
- Who is advocating for this? - Which two (or more) team members pattern recognized this problem?
By asking the five big questions, we stop looking at problems at a micro level, and start analyzing on a macro level with a focus on the effects our problems have on our stakeholders.
I've seen teams track this through shared spreadsheets, JIRA boards, even using sticky notes. Whatever it is, keeping a parking lot does two things:
- The team is organized when we start working with other teams
- The team starts learning from one another and starts collaborating... because patterns require more than one datapoint from one person. By keeping track of who is advcating for what issue, it encourages team members to break their blinders and work alongside their colleagues.
Monthly Pattern Showdown
Every month, the team should take an afternoon and review everything that is in the pattern parking lot, the key is every problem is reviewed.
We analyze the parking lot in the order each issue is received. The team gets to question the ones who advocated for the pattern, and the team decides to prioritize the issues into three buckets:
- Must Have - We have to address this immediately because it would drastically change the course of our business, no matter the time horizon.
- Could Use - We can address these issues because it would drastically improve productivity or client happiness, but not addressing them will not end worlds.
- Would Be Nice - We should address these issues because it would make all of our stakeholders really happy, but it should only be addressed after #1 and #2 are cleaned out.
Throughout the exercise, teams will debate on effect and urgency. Some issues will merge with others. Others will fall right off the board entirely. Sometimes, team members wouldn't realize that their client's problems are part of a bigger issue and some issues will get escalated. I remember on one occasion two team members brought up a problem, within minutes the team is adding more concurring information with their own client experiences, and shortly after that we held an emergency session with the development team to address what was a "would be nice" only a half-hour earlier. Forums like this tend to bring out the best in the team's problem-solving abilities that tend to get duller the more we spend time apart.
The last part of this exercise is: Assign next steps. A parking lot can quickly become a place where issues go to die if nothing gets actioned on. The team is investing their time and effort in this process to help push the organization forward, and will lose trust if they don't see effort being converted into results. Each issue needs to be followed up on - It can be setting up a pattern recognition meeting with product, opening a low-priority bug ticket, work with marketing to develop consistent messaging... Whatever the action is, it needs to be assigned and executed.
It is worth repeating: Not taking action will destroy trust and make everyone cynical about the entire process
Our professional services team can do so much more than just implementing and doing what's in the moment. Taking the time to step back, collaborate, storm over ideas, and pattern recognize issues helps the entire team to improve their knowledge and helps the organization respond to icebergs that may not be visible at the moment. Try out the three-step approach to scrum daily, maintain a healthy parking lot, and storm monthly in a pattern showdown and start your PS team down the path of thinking ahead rather than just reacting behind the 8-ball.