The advent of “Software as a Service”, or SaaS has been a game-changer for the business world, and a career starter for myself. Nevertheless, I feel that the acronym should be reversed.

These past few years, I have been building B2B applications, e-commerce websites
and other services through the perspective of a software engineer. While
striving for quality from a technical standpoint, I have missed some elements
that actually are characteristic of a successful product, and thus of an
effective service.

From a technical standpoint

Software quality, by means of having complete test coverage, writing
readable and robust code, is by no means a bad thing, or a burden. I have
certainly not abandoned those habits, quite the contrary. Those are
prerequisites, a part of a whole, without which I cannot even begin to
pretend to offer any kind of service.

Software quality is not enough by itself, I have to go further.

While professional development makes for a solid foundation, if software doesn’t
actually solve any problems, quality and performance do not matter.

To a business standpoint

Developing a product from scratch, and starting
to sell the code I wrote myself gave me a new outlook I could never have
understood as an engineer working in an agency. It is at that moment that I
realized I was selling the wrong things.

Users don’t want effective software, they want a solution to their problem.

When I was talking about the awesome features I painstakingly built, I was met
with either blank stares, or polite enthusiasm. When I changed my tone, and
started talking about saving users several hours of work a week, or helping
them grow revenue by 10-20%, and so on, enthusiasm became cheer, engagement
started to grow.

At that point, it dawned on me that I should never be measuring success by
quality of implementation or feature richness only, but also, and mainly, by
how many actual real-life problems a product can solve.

It is now clear to me that I am not building software, I am building service.

The fact that the solution is packaged in a web or mobile app is entirely
secondary. The underlying technology is not a selling argument, it’s food
for debate with colleagues.

Reversing the acronym

Service as Software has now become the guiding principle of my career.
With this clear goal in mind, not only have I found a path to carve and follow,
I know my intent and efforts are both directed to improving the daily life
of my clients, and in turn, my own.

This paradigm shift has, in turn, changed my “definition of done”, my priority
scale, and the length of the proverbial “extra mile” I am willing to go
to help solve problems.

Definition of done has gone from “tests are passing”, to “this feature
works as intended, communicates clear success, empty and failure states,
has accessible and efficient UX, and is actually the simplest way to solve
this problem.”

Priority scale takes into account the urgency and/or the amount of
daily pain the feature would be alleviating.

The extra mile is listening to that gut feeling I get every time I know
something could be done better, could become easier to use, even if it would
mean more development time for me.

Wrapping up

It took me the better part of a year, and a few single epiphanies to reach
this conclusion. While I’m very happy to see open road ahead, I’m staying
mindful of how much of a commitment adhering to this principle entails,
and will be improving upon both mindset and technique in the coming years.

This is an ongoing, career-long process.

Leave a Reply