Release Early: A Case for a Strong 1.0 When it comes to the idea of "Release Early," it seems that no matter what you release, if it's not up to a customer's expectation, then it's no good.

I am not a fan of the “move fast and break things” mantra that Facebook used to hold and I don’t think there’s a reason to have to justify my opinion on that. I’m glad they’ve sense moved away from it (or appear to have – I don’t know what they do internally).

I am, however, a fan of the “Release Early” idea. Sometimes this is also coupled with “Release Often” so we get the near-infamous “Release Early, Release Often” phrase in the software development nomenclature.

I don’t necessarily think they have to go together.

But when it comes to the idea of “Release Early,” it seems that no matter what you release, if it’s not up to a customer’s expectation, then it’s no good.

And I get it. At least from that perspective.

But what if you’re a fellow software developer and have some insight on to how this kind of stuff works?

Release Early

The catalyst for this post is that Spotify recently released an Apple Watch application. Their first version is a remote for the application that runs on your phone. This isn’t the first Apple Watch app to do this.

Release Early: Spotify

That is, this isn’t the first app of its kind to have its first version be “nothing more” than a remote for the primary application on the phone.

There seems to be more critique around this particular product, though. I can only assume it’s because the Watch is not at the same place it once was so people’s expectations are higher.

I don’t necessarily hold the same view, though. So before I share my reasons as to why, I want to clarify:

  • I’m a die hard Spotify fan. It’s my favorite music service by far.
  • The cellular ability of the Apple Watch is what put me over the top for getting one because the ability to go out and be untethered from my phone for a date, for a run, for an errand, and so on has been great.

Finally, other applications have gone this route, too. That is, they’ve gone with the “glorified remote” app first and then continued to iterate from there.

And that’s where I call into question some of the critique.

Two Types of Applications

At a fundamental level, I think this can be reduced to customer expectations and I believe those can be separated into two categories:

  1. Companion Applications. Think of these are your remote applications that help control the main application running on another iOS device.
  2. Fully Developed Applications (for lack of a better term). Think of these as full applications that aren’t dependent on any other application but may share data at some point (via a wireless connection, LTE connection, and so on).

And this is where customer expectations vary.

It Doesn’t Imply Lack of Polish

When an application is released from the Apple Watch, we’ve begun to expect that it will be on par with it’s iOS counterpart. I believe part of this is because of how powerful the watches (and watchOS) have become as well as what we’ve come to expect from the various mobile apps that we have.

Secondly, I think that the longer a certain piece of technology is available, the more common “fully developed” apps (versus remote counterparts or companion apps) are expected. This means when you release a companion application, then you’re automatically setting yourself up for critique.

But critique isn’t inherently bad (nor is it good). The manner of critique, sure, critique is neutral as far as I’m concerned.

Further, if the first version of an application is a companion application, that does not mean that it isn’t polished. It just means that it’s tethered to the primary iOS application. And, in my opinion, that’s okay for a first version. I’ve long been an advocate of what I call a strong 1.0.

You can have a well-developed, polished first version that isn’t “feature rich” and that also is not bad software. If it’s a well-polished application, then doesn’t that give the developers room to move upwards?

Get Feedback

As far as I’m concerned, releasing a strong 1.0 is a smart move because it shows:

  • the current level of polish of your application,
  • the direction that you’re planning to take the product,
  • gather feedback and reviews from users,
  • and prepare to move forward.

Sure, as I previously mentioned, you’re going to be opening yourself up to critique of all kinds but that doesn’t matter how feature rich your application is. Everything is going to be open to critique and it’s going to receive it.

What the developers do with the feedback is what matters. And generally speaking, I believe that developers will take thoughtful critique into consideration as they iterate on their software.

Iterate and Do It Again

As developers continue to iterate on their product, they are [hopefully] going to make a better product. Most of the time, this is what I’ve seen happen.

Release Early: Overcast

I’ve even seem some companies have a feature rich application, remove features, and then come back with features previously removed because the operating system of the device changed. (Case in point, Overcast.)

Anyway, the idea of dismissing a product after it’s first version if it doesn’t meet your expectations may be a knee-jerk reaction. I don’t think it’s correct to assume that the first version is the main version. Nor do I think it’s wrong to be disappointed.

Simply put, I think that it’s an opportunity for the developers to ship a well-polished companion app, gather market research, then continue development and repeat the process.

Not All Products Are the Same

Of course, not all products are the same. Take Audible, for example. They were completely stagnant as it related to the Apple Watch despite the fact that people would absolutely listen to audiobooks without their phones.

Release Early: Audible
Okay, so they didn’t release early.

Then they released a fully-developed application. It took multiple versions of the Apple Watch to be released before doing that, though. But that’s the route they chose. And that’s fine.

But if you’re going to be one who critiques the companion applications, I think it’s okay to ask:

  • would you rather have a fully developed application released years after the primary device has been released,
  • would you rather have a companion app released and iterated on quickly?

Of course, there’s at least one more choice, right? It’s not a true dilemma.

  • would you like to see a fully-developed application released as soon as the device as been released?

I’m sure many of us would prefer the latter but we are, as developers, constrained by the systems in which we work. So we have to remember that.

These Are Just Musings

Ultimately, all of the above are just musings on the state of the watchOS market and some of the feedback that I’ve seen. I think the attitudes can translate across markets of software, though I don’t necessarily know how I would make a case for it in the case of WordPress just yet.

Regardless, I find that looking how others behave with respect to this type of software and the economy in which it exists is an opportunity to learn how to operate effectively within software.

If nothing else, it just enforces the idea that you can’t please all the people all the time, but you can certainly please many people a lot of the time. And perhaps that’s the best goal at which we can aim.

Perhaps I’ll have additional thoughts on this later, though. That seems to be the case.