Bottom-up approach and how it turns out
In my company, we follow a bottom-up approach that allows tribes to decide their initiatives for the next quarter. This is a new experience for me as I have never really done brainstorming sessions in discovery phase. My experience was mostly implementation brainstorming.
For this brainstorming session, we were given a not-so-clear mission which is to create “a new online to offline journey”, specifically for mortgage. We kept this mission in our mind and researched about our users.
Our brainstorming session follows the process below:
For 2 days (3-hour sessions), team members got together and discussed ideas based on Desirability and Feasibility. Finally, we formed up a new customer journey.
I think the decision making process achieved certain results so I scheduled a feedback session with stakeholders (read boss). The feedback was that we over emphasised on Learn stage while lacking initiatives of important parts like Apply stage. Our boss focused more business initiatives that geared towards certain feature to increase the conversion rate. In another word, most of the initiatives we proposed did not match with stakeholders’ expectation.
Sitting here and reflecting back on what went “wrong”, I think there are few reasons:
If I could travel back time and re-do this, how else could I have done? To come up with a customer journey that balances user and business, business can’t be an afterthought. Hence, the process could be:
There’s a caveat. If we want to want to go with this approach, the idea generator should have a sense of both (not necessarily 50–50). In our original brainstorming session, although we followed user metrics, our ideas were wild and in different dimensions. If we have to add 1 more dimension, with our team members’ backgrounds (tech vs design vs PM vs researcher) and dynamics (talkative vs shy), the result might be very fragmented and consumes lot of time to align.
Another way is I, as a PM, can reduce the scope from the beginning. I could’ve narrowed down the scope, and before bringing it to the team, the scope should be verified with stakeholders to avoid misalignments. For example, the scope given to the team should be “How can more users apply through us from comparison stage?” If the team disagrees on the scope and suggests to focus on other problems, we could split into 2 teams to work on 2 issues and start a debate. We still need to hit 2 dimensions in this case. Before doing, whatever we say is just an opinion, why don’t we work in 2 teams and work out which part would bring more benefits to both users and business? That might help the final customer journey better.
Anyway, that is a good learning experience for me. On a good note, brainstorming, whether it has achieved idea or not, is a good team exercise for us to understand each other’s dynamics and working style. It makes people feel responsible towards the team’s goal.