The need for speed is paramount on fast-paced, fast-growing organizations as your competition is on fire… and so are you.

The (ultra)lean agile product team is an interesting case study for this sprinting mindset where speed is everything and long term means a few weeks.

Figuring out the place for strategic thinking in this environment is challenging. The strategy is not something you change at the speed of light. Well….  you can do it but unless you are sailing single handed… It’s going to be a challenge for your crew to understand it as it lacks a common purpose, mainly “the why you are doing what you are doing”

Nowadays we have lots of quantitative data to help out on both strategic and tactical decisions on a boat. The catch is: If you only collect and analyze data (the wind, the current, the speed, the performance of the boat,…) will you win at the end of the day?

Sure you can win, by knowing the “what’s” and the “when’s” but only if you are far better then your competitors.

On the other hand, if you race with top teams you only have the chance to cross the line first if you have someone(s) who can help you read the full picture the “How´s” and the “Why’s” and that´s a lot more then quantitative data dashboards… Yes, modern sailing boats have lots of these too.

Balance

On the business side of things, we need balance, and some of this balance comes from user research and field knowledge. A source for the How´s” and the “Why’s.

Back to the (ultra)lean agile product team… The agile process formally values the principle of collaboration with customers and users… (no news right…) so:

  • When was the last time you interviewed your users?
  • When was the last time you validate requirements systematically in the settings of use?
  • When was the last time you involved actual end users?

But we still call requirements the user stories… interesting. What´s the point of it?

My best guess is that it creates an illusion of user requirements. After all, we are looking for impact and product adoption from users. This illusion of user requirements fools both product teams and management. It´s relevant to create a sense of urgency to understand the “How´s” and the “Why’s”, not doing so is dangerous as it neglects or mischaracterizes the target users needs and their environment.

The illusion of safety and control provided by the “what’s” and the “when’s”, relying upon internal proxies to look inside what we should be discovering out there where the action takes place, is similar to sailing a boat not looking outside the cockpit.

Full-fledged quantitative data-driven approaches with little room for user research, field knowledge, and environment understanding are one of the key reasons why teams get into trouble when products fail in the marketplace.

When the stakes are high, the environment is hostile and changing fast, the key to change lies on getting your crew/team to hold one another accountable… especially when your life depends on it… not your paycheck or your work reputation.

I must keep this in mind, as on the next few days I am doing an ocean pass crossing.