What Software Development Taught Me as a Non-Developer

Being a non-developer in technical environments can be tough. In the past few years at OnPrem, I’ve had the privilege of working with a talented team of architects, designers, QA engineers, and developers and learned several hard-won lessons along the way.

We’re currently working on a custom application for a major consumer products and licensing client. My last project involved modifying an existing system, so creating one from scratch presented a whole new set of challenges. This time around there was no guidebook.

These lessons aren’t just relevant to the tech industry — they are easily applied outside of product development as well. I keep coming back to these specific mantras, because they have fundamentally changed how I approach problems and have raised the bar on what it means to be complete.

There’s No Room For Maybe

There are generally times in the business world where using the word “maybe” is OK, but this isn’t so in product development. Being ambiguous in a deck can be used as an advantage to appease a wide audience, and though it might require ironing out later on, it isn’t going to crash the presentation and reset the projector.

I learned quickly in product management, especially when providing requirements to engineers, that “maybe” just won’t cut it. I found this incredibly frustrating at first — of course we might need that feature at some point! But I stuck through it, rewording the requirements to meet the detailed standards of my peers, and found myself using the word “maybe” less and less. My team’s aversion to ambiguity was a conscious effort to build the best product possible with the most efficient allocation of resources.

Our goal is to have an intention and game plan for every scenario. If I’m not sure whether an integration will return “five”, “5”, or “cinco” is it really the best source for our data? Are there other “maybes” related to this integration we need to address? Is the integration an unnecessary detour towards the real MVP of our product? By making an effort to avoid the word “maybe” I refined my surface requirements to reveal the important questions at hand.

Work In Edge Cases

Edge cases account for the extremes, the random situations you never expect. These scenarios are not easy to think of as they require thinking outside of the typical use of an application. At times I’ve provided an initial set of requirements (the happy path) and my developers have come back to me with a very real scenario that had not crossed my mind (an edge case).

After years of observing user testing I am still surprised at how new users approach an application. They try things, push buttons, and they surely don’t read instructions. All of a sudden these so called edge cases become just as common as the perceived happy path.

Working in edge cases has allowed my team to catch some of these surprises before product launches. They have also allowed us to stay one step ahead of our users, building functionality they need, but never knew they wanted. For the times that we don’t think of a scenario, thinking outside of typical user behavior still prepares us to pivot when we are off. Edge cases allow you to flush out your product, creating a more worthwhile solution for the end user.

Working in edge cases translates outside of technical product development as well. Customers and clients introduce unforeseen curve balls to many initiatives. An entrepreneur creating a health syrup that people enjoy drinking…over 100 years later that original health syrup is the world’s leading soda. Even if you don’t come upon a major pivot, working in edge cases allows you at the very least to get a better idea of limitations and project potential.

The extra time spent working in definitives and thinking through edge cases will pay off in the long term with a more refined and confident result.