Han(h)book

Learn to live • Live to learn

2020-03-14 00:00:00 +0000

Brainstorming

Bottom-up approach and how it turns out

Background

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.

Brainstorming with team

Our brainstorming session follows the process below:

  1. Researcher split the customer journey into main stages. In our case, it would be Learn, Compare, Apply and Usage.
  2. For each stage, research shared user insights and jobs to be done (JTBD)
  3. Team member contributed ideas that corresponded to JTBD.
  4. Research and PM came up with a customer journey based on JTBD and several ideas. This serves as a discussion’s starting point.

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.

Checking with stakeholders

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.

What just happened?

Sitting here and reflecting back on what went “wrong”, I think there are few reasons:

  1. The problem is not clear. Well, it’s a discovery phase. If it’s clear, then there’s no need to discover.
  2. 2 sides (team and stakeholder) approached the “problem” (that we defined by ourselves) from 2 sides: user-oriented and business-oriented. That’s why it has a clash right from the beginning.
  3. Personally, I think each side has its own point, and no one is wrong. As a team, our approach is so user-oriented that it lacks business success metrics. So when the boss suggested a business-oriented, the team couldn’t protect our ideas based on his grounds (business metrics). I think that’s why we lost the battle.

What could’ve happened?

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:

  1. Researcher split the customer journey into multiple stages
  2. For each stage, there must be a business target and a user target (JTBD). So any idea would need to satisfy the 2 criteria. For example, a “Share this loan package” feature (1) helps user involve their partner in decision making process, (2) thus helping MoneySmart expediting time from Comparison to Application. I think we only articulated the first part, missing the second part, thus giving stakeholders a wrong impression. Looking back at this idea, I would feel the business justification is not very strong to convince stakeholders — who in this case are more business-oriented than users-oriented.

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.

What could’ve happened? (part 2)

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.