More useless software?

Dear adventurer,

Are you familiar with the “superbloom” happening in California right now? After more than a decade of drought, my home state experienced epic rains and snowfall. There were terrifying mudslides and floods — many lost much.?

And then the sun came out.

Wildflowers that lay dormant for years are exploding with life. Vibrant orange poppies are squeezing through sidewalk cracks. Once arid mountains are now tie-dye technicolor with swathes of yellow, purple, and green. As an avid outdoor adventurer I am almost overwhelmed at the drastic difference — there is an element of chaos. We went from nothing to everything all at once.?

I think there is a parallel here for product builders too. Variety and abundance can be enjoyable — but only enjoyed if there is careful consideration about the best way to achieve it. Otherwise, our customers and teammates may end up in a dusty desert wondering when the next superbloom will happen.?

You can read it first: 7 ways to avoid building useless software?

Problem identified. Now, how can I solve it??Product managers ?confront this question every day. (Usually many times a day.) Most folks would say that the first step is to methodically evaluate the issue from all sides so that you can define the problem clearly. But I would say the examination is not the most important part of solving a thorny problem. It is the motivation and mindset of the person doing so that matters.

Those of us who build technology products are well aware of the stakes — it takes fierce dedication to create something truly valuable.

I have been building products for decades, culminating in a?software suite ?created expressly for fellow product builders. As the co-founder and?CEO of Aha! ?I remain deeply involved in product development and speak to customers regularly. So I can say with experience that building anything new is always a risk. There is so much that is not within our control. And it simply is not possible for everything we create to be additive — eventually something detracts.?

More features do not always make a better product. Often it is just more stuff. So, I decided to jot down my best advice on how to avoid building software that no one uses →?Read the 7 steps here .

You said it: A little more understanding will go a long way

I posted this poll when I was working on the blog post I mentioned above. Although I had already written a post about the signs you are not building what users want (you can read it here ), I was curious what else folks believe causes software spoilage.

The preponderance of votes pointed to the same culprit: poor customer understanding. And I agree. To build anything of value, everyone on the team must be clear about what customers really need and want. Otherwise you are just guessing.?

But I always caution product managers that you do not want to let your?customers create the solutions ?— your focus in this understanding is to tease out the problem (even if customers are not yet aware of it fully).

There were some comments with additional reasons not listed in the poll that caught my eye as well. Like this one from Tammy Tibbles: “Changing priorities mid-sprint.”

Certainly things can emerge during development that no one could anticipate — life is full of surprises. But if you find that the one constant is how frequently directions change? Not a good sign. It likely means that leadership is?fuzzy on strategy ?(if there is one at all) and the trickle down effect is leaving everyone feeling frustrated.?

I also saw this comment from Jim Coyle: “Poor requirements definitions upfront.”?

There is a fine line here that most product leaders try to toe appropriately. You want to give the development and design team enough detail to inspire an elegant solution — but not so much that they feel they are being dictated to and turned into production machines.?

Which leads us to the next comment. Ka Kwok added: “Too much noise during development.”?

Most of us who work in SaaS are passionate about every aspect of the product development process — we want to stay close to every phase to ensure we are delivering the most value. But depending on the size of your team and how many folks are offering input, that noise can affect velocity.?

Noise reduction comes down to a few factors. Consistency in decisions circles back to a goal-first approach, deep customer understanding, a thoroughly vetted?roadmap , and a product team that acts as one — not a collection of individuals

You help me: Can we bloom in a drought?

This is my second edition of?The Startup Newsletter ?using the new format. So far it seems like you are enjoying it — I know I appreciate having a consistent framework.?

Lately I have been thinking about the new constraints on product teams. How do you harvest more with less? What challenges are you facing right now? What do you think is going to define the remainder of 2023? And how can I help?

Let me know what is on your mind.

Yours in nature (and increased pollen),

Brian?