An abstract illustration showing a spinning arrow with multiple alternate directions.
Re-aligning the team direction.

Responding to tough feedback on your product direction

How we handled unexpected feedback, re-aligned the team, and justified sticking with our original plan

Katie Le
Published in
5 min readDec 20, 2021

--

Hi! We are Nicolas Backal and Katie Le, product designer and product manager at Okta. We have been working together for years, and we want to share the lessons we’ve learned through the lens of a cookbook with detailed recipes for creating a great design-product partnership.

We were working on designs for our product’s first release and we wanted to share and get feedback from our leadership team — let’s call them e-staff. We went to the meeting feeling confident and demoed what we thought was a great experience. To our surprise, we were told that what we demoed was not great and that we were actually making it harder for users to use our product. What?? 😱 😞 😭 .

Ask questions under pressure to understand why

Before blindly agreeing with e-staff, we asked them to clarify why they thought the experience was harder to use, and most importantly, for whom. From this question, we learned that they were concerned about a different user persona than the persona we designed this demo for. Either way, their concern was valid. E-staff’s focus on a different persona — let’s call her Alice — made us question our strategy, and we told them we’d come back in several weeks with a proposal for the next steps.

Thoughtfully explore and evaluate solutions as a team to the prompt

Over the course of 2 weeks, we focused on “The Alice Problem”. The core team did a half-day value proposition workshop focused on Alice (see ingredients for exactly what we did). The output of the workshop was a storyboard outlining 3 possible solutions to The Alice Problem, and Nicolas created low-fidelity mocks to visualize each solution. Next, engineering used basic tshirt sizing to show how expensive each solution was. Last, Katie grabbed data on the size of the Alice population. It turns out the Alice population was small (~10% of our target user base), but also represented a power user. We weighed the cost of supporting one of the solutions, all of which were power features, and Katie decided (with support from the team) that we should not invest in these power features for Alice over other core features.

Share how your team collectively landed on a recommendation

In our next e-staff meeting, we walked through the user flows and tshirt sizing for each of the 3 solutions. E-staff was happy with the result, which was great because it showed that we were thoughtful and deliberate about considering a different direction. We then showed the data and posed a tradeoff question back to e-staff. Are any of these solutions worth building if we now have to give up N other features that benefit the majority non-Alice population? We shared our recommendation to de-prioritize The Alice Problem, and we argued that the demo we originally showed was a good enough experience for the Alice population for the first release.

Have confidence in your direction (if you’re talking to your users)

In the end, e-staff gave us the flexibility to decide when to solve The Alice Problem, but they appreciated seeing their concerns addressed and that we put in the hard work to create the best user experience in the long run. We ended up back where we started with our original demo, but everyone was now aligned. It’s easy to give in and think that your leadership team knows better than you, but as the individual contributor with boots on the ground talking to customers, you should remember that you also know your users and your product’s technology really well. Be opinionated about the direction you think the team should go in!

Recipe

  1. Show designs early to your stakeholders so you don’t go too far down a path without alignment
  2. If you receive constructive feedback on your product’s direction or design from significant stakeholders, pause and ask questions to understand the root of concern
  3. If the problem or misalignment is big enough, do a value proposition workshop with your team framed around the root of concern and come up with solutions
  4. The designer should create low-fidelity mocks for each of the solutions quickly (1–2 days to be shared with the core team, 1 week to be shared more widely)
  5. The engineering lead or architect should come up with a high-level estimate of how hard it would be to build each solution
  6. The PM comes up with a recommendation to share with the leadership team with justification. It’s the PM’s job to have opinions. Get alignment with your core team first so you’re not surprised at the meeting
  7. In your presentation, bring leaders on the journey with you by reviewing the prompt, showing demos of each solution, reviewing the cost to build, and sharing the tradeoff decisions you had to make to land on your recommendation. It helps build empathy with your team and shows the rationale behind your thinking

Ingredients

  1. A brainstorming tool like Figjam or Miro to run a value proposition workshop. You’ll need an empathy map to understand the user deeply, a how might we exercise to define our problem statement, and a scamper exercise to spur ideas for solutions
  2. A design tool like Figma to create low-fidelity user flows
  3. An engineering level of effort exercise like Tshirt sizing to evaluate the cost
  4. A method to explain trade-offs in a very clear and concise manner. We like to use tables with a title for the option, a description of the user experience for each option, the pros/cons of proceeding with that option, and a visual indicator highlighting the recommended option.
  5. Presentation tool of your choice to create a deck for readout

Thanks for reading our recipe. Our goal is to share our experiences working together using a short-read format with instructions that you can try on your own — just like a cookbook. We hope you found it useful!

Katie Le & Nicolas Backal

--

--