When The Solution Is The Pivot

Ever work on that picture perfect project that has multi-level executive sponsorship, budget, a clear problem definition, an agreed upon and clear solution direction and the granted autonomy to whatever is necessary for success? On this picture perfect project, have you ever delivered everything communicated by the customer and a little bit more, finished on-time or earlier and on-budget or under? Have you ever discovered that the solution you've provided as requested actually revealed that you've solved the right problem at the wrong time in the customer's history or even that you possibly solved the wrong problem altogether? Me neither. I'm just making this stuff up.

It is normal for a customer to not know what they want until they see what they don't want. This happens frequently, though is difficult for people to admit for fear that they may be looked upon as indecisive, inexperienced or simply ill-prepared to handle the task at hand. Particularly in a situation whereby we're delivering solutions in a two-week incremental delivery model, it is not unusual to watch the deliverables from a single two-week iteration stimulate the customer to change their minds. Whether a redefinition of the problem is in order or next revision modifications to the deliverable direction, sometimes data suggests the need to change or pivot. According to experiences I've personally had with multiple customers through the years, this is all contextually normal.

If you don't know what you really want, or you need to verify that what you want is actually useful, discover it in short two-week delivery bursts rather than painfully blind, multi-month payloads. It is okay to not know something, but you must be willing to discover the answer incrementally and then pivot as needed.

  1. What problem do you want to solve?
  2. Is it the most important problem to solve?
  3. Who will benefit by you solving this problem?
  4. What are the possible solutions to the most important problem?
  5. Which solution path makes the most sense?

How can you discover if the chosen solution path makes sense in the shortest amount of time, with the least amount of effort, cost and complexity? Instead of focusing on the solution alone, how can you discover if you're even solving the right problem?

  1. Who are the potential users of the solution? Which one should be addressed first?
  2. For the highest priority user, what are the potential uses of the solution, prioritized?
  3. Each potential use of the system needs to be end to end, e.g. login, activity thread, logout.
  4. Take the highest priority activity thread for the highest priority user and decompose the work down into one or more two-week consumable deliverables.
  5. No, it won't be performant, infosec hardy or your best work of engineering elegance.
  6. Yes, it must be end to end built, tested and demonstrable at iteration end. No bells, no whistles, no pomp and circumstance. Just raw data illustrated by tested, demonstrable solutions.
  7. Based upon the chosen problem statement, hypothesize a solution and thereafter validate or invalidate it as soon as possible.
  8. Repeat for each user and activity thread until you're justifiably done. Pivot as needed.

If, after some number of two-week iterations, the answer you receive from your efforts seems to suggest you're working on the wrong problem, working on the right problem, but the wrong timing and/or you're walking down the wrong solution path, are you willing to pivot?

Question: If the data suggests a need for change, but you're not willing to do so, are you really interested in solving the real problem?