Learning the Purpose of Software
I believe that the purpose of software is ultimately to make people’s lives better. Standing on a soapbox and proudly declaring this now, in 2019, is sure to cause the most colorful Captain Obvious memes or fervent eye rolls, but the truth is that I didn’t always harbor this conviction.
But they say that “experience is the best teacher” and I was fortunate enough to have an experience educate me and fundamentally change the way that I saw things.
The rest of this post is about that experience, why I didn’t see things that way beforehand, and how I now maintain a user-centric approach in the world of software and product development.
My first application for users… who weren‘t me
During the summer of 2003, I was fortunate enough to land an internship with Sun Microsystems and join a team that wrote system software in C for a line of enterprise servers. This was back when companies typically bought their own servers and before the rise of cloud computing and Platform-as-a-Service offerings.
One of my projects was to create web-based software that would enable my team to communicate project status and details across the 30,000 person company. It was basically a Content Management System (CMS) like WordPress or SitePoint, but for a number of reasons, my team opted to build something internally ourselves. And because all of the other engineers on the team needed to focus on writing system software for the servers, building the CMS application went to me.
Although I had spent years dabbling in software by this time, this was the first time that I had actually needed to create software for other people to use. This became abundantly clear to everyone after I “completed” the project because what I ended up delivering was a monstrosity:
- The UI was a mess. Using the application required reading 3–4 UPPER CASE paragraphs of instructions to understand how to use it. All of these instructions were above-the-fold when you loaded the page; the UI elements to start actually using the application were below.
- The UX was under-designed…or not designed at all. The application could only be used in conjunction with another system with a very specific and inflexible sequence. To create a new page, you had to first enter information in one system, then enter the additional content you wanted to publish in the one that I had built, and then go back to the first system to publish. To add insult to injury, there was a different sequence you had to follow with both systems when editing, and yet another one deleting.
- It didn’t support key written communication use cases. At the time, I didn’t know how to escape characters like apostrophes and so including one in certain forms would break the application. So instead of figuring out, I simply said — in those UPPER CASE INSTRUCTIONS — that you couldn’t use apostrophes. That’s right, I told users of a CMS meant to publish information that they couldn’t include a common character like apostrophes; that writers weren’t allowed to show possession!
- It didn’t support large volumes of content. If you made it all the way through the flow, and somehow figured out how to publish content, the published content wasn’t easily readable and so it wasn’t even as effective in helping readers understand the information shared. I hadn’t tested content above a certain, relatively low character limit and so attempting to publish at a normal volume meant that content bled over from one section to the next other and beyond margins. Just a few minutes and even fewer paragraphs of lorem ipsum testing would’ve surfaced this issue.
I could go on and on about this but the point is that it wasn’t good. In fact, it was downright awful, but I was blinded to that fact the entire time I was working on it.
It wasn’t until I presented to my team that I realized that something was amiss. Although I was excited and full of pride while presenting, I keenly remember my colleagues looking strangely at each other throughout but not knowing why.
My manager at the time, Alan Slivensky, pulled me aside after the meeting, compassionately asked me how I thought it went to which I expressed bewilderment. And with a slight smirk, he said some words that changed the way I thought about software forever:
“Software is meant to make people’s lives better”
Duh — How is this news?
Those 8 words — “Software is meant to make people’s lives better” — convey a truth that may seem obvious as you read this now, but they weren’t obvious to me back then.
Before this experience, all of my formal education around software had been about the how of software — learning the mechanics of software and being able to produce code that compiled — and not necessarily the why — such as the business of software or its role in helping people achieve outcomes.
And before this experience, all of my time hacking and informally dabbling in software had been primarily about exploring, feeding curiosity and generally just doing what I found to be interesting for the sake of learning.
And so when I was asked to build software for others, I used it as an opportunity to geek out a bit more on something that I, personally, wanted to learn more about. I don’t know what would have made the most sense back then but at the time, I was curious to learn more about Perl, HTML and CGI…and so I decided to use Perl, HTML and CGI to build the CMS.
There was no real thought about the user’s goals; no concern about user experience; no user testing… or talking to my users at all. As far as I was concerned, this project was an opportunity for me to learn additional languages and concepts.
With that mindset, it would’ve been impossible for me to actually deliver something that added value to my users because the truth was, I wasn’t thinking about them.
Charting the right course with User-Centricity
This experience was years ago but I still think about it regularly and cringe every time. But the truth is that I’m still regularly tempted to approach product development this way, albeit, not in as extreme a manner.
If I’m not careful, I may fall in love with an elegant solution and not my user’s pain points; a set of bug-free, well-built features and not what a customer can accomplish with them; clever use of email marketing copy and not whether they successfully convey messages to users and convert; a sleek UI and not how well the design converses with the users who interact with it.
And so I use this experience and the face-palming emotions it elicits as a cautionary tale on the horrors of not being user-centric.
In addition to this cringe-worthy memory, there are a couple of things that have helped me stay user-centric over the years.
The first is this image:
Maybe it’s because I grew up playing Super Mario Brothers but for whatever reason, the moment I saw that image, I could not unsee it. It’s what I visualize when I think about the idea that software is meant to make people’s lives better.
People use software to do something better, faster, more efficiently or more effectively. And they stick with them because doing so means that they’re now able to accomplish things in ways that they couldn’t before. It’s all about them and if you stray away from this approach, your users will inevitably stray away from you.
[During my internship at Sun, I thought that I was Mario and not my users. I was focused on ensuring that I could do rad shit (do more with Perl, HTML and CGI) instead of making sure that my colleagues across the company could.]
The other thing that helps me stay user-centric is a set of questions that Gibson Biddle would reinforce that product managers constantly ask back when I worked at Chegg:
- What are we solving for? This fundamental question should be asked before embarking on any software effort…or maybe any problem-solving effort, period. It’s your true north star and will guide your efforts and help you stay on course. It also helps you think about who you’re solving for — your users or customer — because without knowing that, it’s impossible to really understand the problem.
[During my internship at Sun, I thought that I was solving the problem of making Perl, HTML and CGI work, instead of making it easier for people to share and retrieve information across a company.] - How do we plan to solve for it? Dale Carnegie said that “An hour of planning can save you 10 hours of doing”. When developing software, this planning includes things like design and approach, but it should also include reviewing with users (as much as possible) and stakeholders in order to get their input. Doing this not only means that you’re more likely to deliver something efficiently, it also means that you’re more likely to build something that will actually be used by your users to solve their problems.
[During my internship at Sun, I did some planning on paper to figure out my approach but I did not go around talking with my users to inform how we might solve this problem.] - How do we measure success? Value creation is the #1 goal of every product or business, and you can’t know if you’re delivering value unless you have a way to measure it. Starting out every effort with an understanding of the success metrics that you’re looking to improve will help ensure that you put your focus on things that actually deliver measurable value to your users (and business).
[During my internship at Sun, I operated as if the measure of success was me learning new technologies. But the real measure of success was whether my team could communicate more effectively with the rest of the organization].
Together, these 3 questions ensure that you’re focused on the problems of your users and that you’re only tempted to (product) manage what you measure. Although I started asking them after moving into Product Management, I think they’re applicable to just about any role in the world of software. Or maybe any role, period.
Learn from my mistakes
Does this sound familiar? Did you cringe while reading because it reminded you of something you’ve done as well?
Perhaps you, too, have found yourself presenting from an angle of “look what I built” vs “look what a user can now accomplish”.
Perhaps you, too, have found yourself thinking that the problem you were solving for was to make some technology work together, and not solving a user or business problem.
Perhaps you, too, have jumped into implementing a feature or building a product without talking with your users.
Or perhaps you, too, have thought that the #1 measure of success was whether or not you personally learned something and not whether or not value was added to your users.
This is an easy trap to fall into, especially as you first enter the world of software, but it isn’t necessarily limited to a single type of role.
This mindset is what leads PM’s to not speak with customers and instead just build what they think is cool; engineers to want to rebuild an entire application with the newest framework or language or concepts, despite old “boring” ones being good enough to address the customer issues; and for designers to try and incorporate new UI and UX flows, even if it doesn’t mesh with the paradigms that their users are already used to.
Keep front and center that the purpose of software is to make people’s lives easier and if you’re a part of a team or company that develops software, that’s the key focus and what you’re ultimately there to do.
If you start with the user, understand what they’re trying to accomplish, and obsess over how to measurably make their lives easier, it’ll take you far.
