The Objective Blog

Keep up with what we're thinking, reading, and doing.

Software is Never Done

September 22nd, 2017 - by Brett Derricott - Salt Lake City, Utah

For first-time software entrepreneurs, the realities of creating and owning a software product can be a shocking eye opener. The trouble is, most have to learn the hard way. My hope is to give you some insights, gained after 15 years of designing and creating software for hundreds of clients, that will help inform you as to what you’re really getting into when you set out to create a new software application.

Incorrect Expectations

Most people who’ve never created nor maintained software are somewhat unreasonable in their expectations of what it will cost to create software that can achieve product-market fit, and unreasonable in their expectations of what it will cost to maintain that product after launch.

Based on my experience, expectations are often off-base because of the following reasons:

  1. The entrepreneur has never done this before. How could they know any better? If I decided to build a boat, which I’ve never done before, it’s safe to assume the project would take longer and cost more than I naively think it would. The same holds true for a first time software entrepreneur. We don’t know, what we don’t yet know.
  2. They’ve been conditioned to this thinking. There are many other things in business, even within a loosely-related category, that are more “pay $X and then you’re done”, such as a logo, computer, or brochure. Software, unfortunately, is not at all like this.
  3. Historically, software was a bit more of a static product. We bought software on discs and in the pre-Internet dark ages it was rare to get any updates for that product. I think this gives some precedent to the notion that “I’ll build an app and then sell it.” We still buy mobile apps that way, in fact, even though our mobile apps are constantly being updated.

The Dawn of Awareness

One of my favorite conversations with new-ish entrepreneurs is the one we have about a year after they’ve launched their app or SaaS product. By that point in time, the entrepreneur has usually started to realize that they will be working on this app (translation: spending money) continually for as long as they are in business.

They now know first hand that creating and maintaining software isn’t quite as simple as they originally expected. What leads them to this new understanding? It’s first hand experience of the following truths:

  1. All software has bugs. A hallmark of an inexperienced entrepreneur is that they believe in bug-free software. It’s a myth. Certainly, everyone strives toward that mythical goal, but no amount of money or expertise will prevent 100% of bugs. Get used to bugs, learn to prioritize them, and accept that they’ll cost you some money.
  2. Devices, operating systems, and browsers change…and they change often. Each change represents a potential problem for the software product, and some amount of effort must always be dedicated to keeping the software product up to date with the devices with which it must interact.
  3. Technologies become out of date or obsolete. Protocols get updated, libraries and frameworks evolve, APIs change, security patches need to be applied, and on and on. Your mobile app or web app lives within an ecosystem of other code and as that other code changes yours must change along with it.
  4. Your market changes. Even if you could build your product perfectly, your market and your customers are evolving, and that means your product has to keep pace. Your competitors are improving their products too, so forward movement is essential to stay relevant. You will need to invest heavily in your product for this reason alone.
  5. Your success will drive change. As you succeed in winning customers, their needs and the impact they have on your product will drive you to refactor code, optimize queries, build new administrative and reporting tools, etc. Your own success will demand further investment (which is a good problem to have).
  6. Technical debt must be addressed. Technical debt is an uncomfortable concept for product owners. Technical debt comes from tradeoffs developers have to make in order to meet timelines and stay within budgets. If you demand that your developers incur no technical debt, not only are you being unrealistic but you’ll never launch your product because you’ll forever be chasing the mythical perfect product. Technical debt will always exist, but you must devote some resources to keeping the amount of debt reasonable. Ignoring technical debt is also a good way to alienate your developers, by the way.

Avoiding Some of the Pain

Some of what you need to know is only going to be learned through experience. Some of what I’m telling you may not resonate until you’ve gained some mileage. But I do believe it’s possible to save you from at least some of the pain inherent in learning the hard way about the cost of creating software, and the following tips are offered with that goal in mind:

  1. Welcome the adventure. Have the humility to recognize that your expectations are probably a bit off, and welcome the experience of learning what it really takes to launch and own a software product. Like doing anything new, having an open mind and an eagerness to learn will turn your journey into an adventure rather than a frustration.
  2. Start small and conserve budget for the future. Even though you may feel like you have a perfect vision of what you want your app to do, start as small as possible, and iterate your way to that vision. If you do this, you’ll spend less money making the mistakes you will inevitably make. In other words, learn cheaply.
  3. Spend money on quality. While my previous point said to learn cheaply, the point is more about reducing the scope of your initial versions. Don’t go cheap on the quality. Cutting corners on quality increases your chances of having to start over or do a major rewrite of your software later. At least once a month we talk to a company who hired an inexperienced web developer (or an ad agency) to design and build an app for them, and the project is failing. It’s heartbreaking to have to educate them on why the money they’ve spent was nearly all wasted by an unqualified vendor.
  4. Get validation early and often. Validate your assumptions about the market as much as possible before you invest heavily in a product. Part of that market validation does require designing and building one or two versions of your product, but don’t spend hundreds of thousands of dollars trying to build the perfect product right out of the gates. Get validation first.
  5. Educate yourself about technology. You don’t have to become a developer, but if you’re going to own a software product you need to gain some technical knowledge so that you understand enough to manage those who will write the code. The more knowledge you have, the more effective they’ll be, and the more equipped you’ll be to avoid major issues.
  6. Find trusted advisors and vendors. The lowest cost vendor (or developer if you’re hiring internally) is rarely going to get you the quality you need. Avoid the siren song of anyone who tells you it can be done for significantly cheaper than what the other qualified sources are saying. Chances are they cheap vendor won’t deliver what you really need, and the technical choices they make will cause you major headaches and expense down the road. The best development firms are always going to give you a healthy dose of honesty and reality, which is often at odds with what you want to hear. If you’re tempted to ignore their candid advice, read #3 above, and then read it ten more times. You don’t want to be the firm calling us to find out if we can fix the mess you’re in. A reputable firm will also help guide you in terms of how you spend your budget so that you can balance quality with affordability.

The Most Important Question We Ask

September 8th, 2014 - by Brett Derricott - Salt Lake City, Utah

When a client contacts us about a new branding, design, or development project, we ask a lot of questions about the scope of the project so that we can propose an accurate budget and timeline. In addition to questions about the details of a project, we’ve started asking, “At the end of this project, how will you decide whether or not we’ve been successful?” Or, a variation that we’ve been experimenting with is, “When this project is complete, what will make you want to refer us to others?”

You might be tempted to think that the project’s scope is synonymous with the client’s definition of success. We used to think that too, but we’ve learned that’s not always the case. The RFP or statement of work is heavily focused on the what of the project, whereas declaring a project successful requires satisfying the why of the project.

For example, a client’s scope of work may list the following high-level deliverables which comprise the what of the project:

  • Brand refresh, including updated logo
  • New website
  • New business cards

But further discussion about the client’s definition of success reveals that we also need to accomplish the following to satisfy the why of the project:

  • The client wants to clarify their position in the market as the top-quality vendor, rather than compete on price.
  • The client wants to work with a firm that never misses deadlines (their previous agency frequently missed deadlines).
  • The client wants ongoing support after the project’s completion.

The original deliverables tell us what the client needs to have at the end of the project, but the additional details tell us more about the real results the client wants and what they expect from us during the project.

We’re not interested in merely checking off the feature list in a statement of work; we’re interested in happy clients who can’t help but tell others about their successful project. Making this happen reliably requires knowing the client’s definition of success at the outset of the project.

As an added bonus to better understanding the client’s real needs, we’ve discovered that asking this question also helps the client understand what they really want and this, in turn, helps them to better evaluate the various proposals they receive. When they’ve clearly defined the outcome they hope to achieve, the lowball proposals start to seem less appealing and a reputable firm starts to seem like a must-have…and that’s where we come in.

 

Our Disruptive Environments

January 13th, 2009 - by Brett Derricott - Salt Lake City, Utah

With all of the forms of instant communication (or instant interruption) at our fingertips, this article struck a chord for me. Email, instant messaging, social networks, and text messaging sometimes seem like they’re all determined to prevent us from actually getting anything accomplished during the day.

Read this article and share your thoughts in the comments below. How do you keep control of your attention and prevent the interruptions from owning you?

http://www.internetnews.com/commentary/print.php/3793561

Hourly vs. Fixed-Fee Billing

March 26th, 2008 - by Brett Derricott - Salt Lake City, Utah

This post is going to deviate a bit from the technical realm but I just read a report in the latest HOW Design magazine that was based on a recent survey of designers’ rates. One of the questions in the survey asked whether designers disclose their hourly rates to their clients.

The question, as written, seemed odd to me until I realized what they were getting at. This is how they should have asked the question: Do you bill your clients by the hour or do you provide a fixed-fee estimate?

I was disappointed to read that the majority of survey respondents bill hourly for their work.

Read the rest of this entry »

Offering Your Clients the Whole Package

March 23rd, 2008 - by Brett Derricott - Salt Lake City, Utah

When I began freelancing I thought it was important to make my fledgling business appear bigger and more established than it really was. My website used phrases like “our designers” and “our programmers” in an effort to make a one-man show look like a full team of professionals. No matter what a potential client wanted I felt the need to make them believe I had all of the resources to do it.

Read the rest of this entry »