Makalu Blog

The State of Bitcoin in 2015

2015-09-15T00:00:00+00:00

In 2012, a visiting friend from Berlin got me excited about bitcoin. During the next several months, wild price fluctuations, the scent of speculation and spectacular collapses of exchanges like Mt. Gox, caused many to dismiss bitcoin as nothing more than a bubble that would eventually pop and disappear, like the Dutch Tulip mania of the 1600s.

The effects of speculation unfortunately obscured the promise of bitcoin’s underlying technology. With bitcoin, the transfer of value—whether $1 or a million—is instantaneous, irreversable and nearly cost free. And its network-distributed “blockchain” provides a level of transparency and accountability that has never before existed in financial transations.

In 2012, my hope was that bitcoin would survive. Today, in September 2015, I thought I’d reflect on some observations of how its doing.

Price stability & adoption

The price of bitcoin seems to have (relatively) stabilized around $240, as seen in this chart from Coinbase:

It hasn’t reached a level of stability that would give me the confidence to store large values, but nonetheless it’s a promising sign in terms of its liklihood to survive.

In terms of adoption, it’s also promising to see a steady increase in the number of daily bitcoin transactions.

Many, myself included, imagine that there’s only two outcomes for bitcoin—that it will eventually replace gold as the world’s principle non-fiat store of value, or that it’s value will go to zero.

It’s interesting to consider that if bitcoin attained even half of gold’s current $6.5 trillion market cap, the value of a single bitcoin would be worth over $150,000.

Wallet technologies

The emergence of multi-signature wallets allow users to store their bitcoins with providers like Coinbase and Bitgo in such a way that they can’t be lost to hackers or mischief on the part of platform staff (think Mt Gox).

The emergence of hierarchical deterministic wallets allow far greater privacy and security, in that a unqiue address can be generated for each transaction, and the entire wallet can be recovered from a complex passphrase in the case of, say, loss of device.

And for those who want to completely delegate the custody of their bitcoins to a third-party, we’ve seen the emergence of services like Xapo, who currently lead the market in custody of bitcoins held by large institutions (such as the Bitcoin Investment Trust ETF.)

Global financial innovations

As someone who has lived in one country, operated a business in another, hired staff in a third, and serviced customers in a forth, I have direct experience with the friction involved in dealing with border-constrained financial institutions, multiple currencies and slow, costly and outdated monetary transfer mechanisms. (Speaking of which, did you know people still send paper checks in the United States?)

In that context, I’ve been excited to see the emergence of innovative financial products set to disrupt international finance—many of which use bitcoin as an infrastructure or access component, rather than as a currency, exploiting the speed, low cost and blockchain validation benefits inherent to the technology, while mitigating risks associated with bitcoin’s relative price volatility.

Bitreserve is a product created by one of the Salesforce founders, whose value proposition is to act like a bank, but without exposing its customers to the risks associated with traditional fractional reserve banking.

Once you deposit “value” into the platform via a bitcoin transfer, you can then covert those bitcoin into—and exchange between, cost free!—any of several worldwide currencies, or even precious metals like gold and silver. Visually, they present these as “cards”.

And using blockchain technology, the platform allows public confirmation that, at all times, Bitreserve retains physical reserves of all currencies and metals, equal to or greater than its liabilities.

Since the only way to get funds out of Bitreserve presently is bitcoin, the platform seems to be of minimal transactional utility, but they claim to be in the process developing interfaces with traditional financial channels like debit cards, bank transfers, etc.

For the moment, the practical uses of Bitreserve would include, say, holding of one’s cash savings, mitigating exchange rate risks associated with future expenses in a foreign currency, speculation on currencies or metals, or even to retain one’s investment in, say, physical gold (although with a 2% exchange commission, I think BitGold, discussed below, is a better options for that.)

Payment processors like Stripe have integrate bitcoin into their products, allowing businesses to extend product marketing into regions where credit card penetration is lower, but digital currency adoption is higher—e.g. developing nations, and nations with currency instability like Argentina.

Bitwage is a platform working to allow companies to extend payroll services and payments to anyone in the world, from native currency to local currency of the workers, using bitcoin and its network as a low cost and instantaneous transport.

Although not directly bitcoin-related, the Canadian company BitGold has brought convenience and improvements to the area of acquiring, storing and using gold.

Previously I used BullionVault as custodian of physical gold, but eventually left due to its inconveniences; for example, their gold accounts can only be associated with one bank account, and so moving funds into and out of the service proved restrictive and involved costly (and error prone) international wire transfers.

BitGold allow you to purchase physical gold through ACH bank transfer, credit card purchase and bitcoin—and even choose among several vaults worldwide for its storage. (It’s interesting, however, that when purchasing gold with bitcoin, the only vault option provided is Dubai.)

You can sell gold and retrieve funds via ACH bank transfer (to any account you’ve connected) or via a super-convenient pre-paid debit card, available in any of three currencies. If you want, there’s even an option to have your physical gold shipped to your house. Finally, BitGold have promised to allow withdrawals in bitcoin in the near future.

BitGold’s costs are attractive. Purchasing or selling gold is done at 1% within the spot price, and there are no storage costs. I simulated a cost comparsion with BullionVault, who have a lower purchase fee, but charge an annual storage fee. If you hold gold for more than a few years, the overall costs easily work out in favor of BitGold.

Although a relatively new company, BitGold acquired BullionVault’s main competitor GoldMoney, making them one of the world’s largest holders of gold. Exciting stuff!

Future concerns

If Bitcoin succeeds, we can imagine ourselves in a world in which we’re transacting daily with the currency as we would today in dollars and euros, in which bitcoin is used as an transport layer to bring speed, low costs and accountability to fiat systems, and in which we possibly store a portion of our wealth in bitcoin.

A concern I have imagining such a world, is government’s tax treatment of digital currencies. For example, the US government currently treats digital currencies as property, subject to capital gains on certain transactions.

That implies a requirement for anyone using bitcoin to continually track their fiat-equivalent cost basis when purchasing, as well as current exchange rates when disposing of bitcoin. Such a burden would obviously become impractical in the world described above. Just imagine if every time you earned or spent a dollar, you were required to keep track of the current exchange rate of gold. And imagine if having earned $1,000 in January and later spent that $1,000 in June, you could find yourself subject to capital gains tax if, in the meantime, the USD exchange rate with gold had dropped.

Conclusions

Given its relative stabilization in price, observing its continual increase in transaction volume, and witnessing a growing momentum in the emergence of related innovative products and services, I’m more optimistic about the future of bitcoin than ever. It’s exciting to imagine the possibilities that would be enabled in a world in which bitcoin is successful, especially for people like myself, who enjoy geographical independence of home, business, employees and customers.

On the other hand, slow-to-adapt governments already make it difficult for people to operate internationally, and since the widespread use of digital currencies is not particularly in their interests, I foresee governments becoming even larger points of friction in the process of bitcoin realizing its full potential.

In any case, as with past technological shifts, translating unfamiliar concepts into engaging and usable consumer products is an exciting and important design challenge, and one I hope our team at Makalu has the opportunity to take on, whether through helping an innovator’s product to achieve widespread appeal, or in developing our own.

And that’s my current view of the state of bitcoin in September 2015. See you in 2016, and be sure to follow us on Twitter to get notified of the next update.

The Design of Xapo

2015-09-14T00:00:00+00:00

The challenge

Through generations of experience, we comfortably relate to the concepts surrounding traditional stores of value and transactional currencies. As a commodity that we can touch and hold, we have an intuitive understanding of gold. We understand that we can put it in a safe or entrust it to a custodian like Brinks. When we transact in gold, we understand that we’re passing ownership of a physical object from one to another.

We also tend to relate to fiat currencies like Dollars, Euros and Pesos as physical objects, although their realities are more abstract. Like gold, we intuitively understand that we can secure and transact ourselves in physical cash, or we can entrust its security and access to the vaults, credit cards and transfer services of banks.

Bitcoin represents an entirely new paradigm. There’s nothing physical about bitcoin. The “owning” of a bitcoin means the “controlling” of a complex number known as a private key. If we try to relate that private key to something with which we have familiarity, it would be a “wallet”, or a bank account. But whereas most people have one wallet and one checking account, with bitcoin it can be advantageous to create a new private key for every transaction we make!

For products offering the storage, security, and access to one’s bitcoins, translating such foreign notions into concepts that are approachable and understandable by consumers and organizations represents a considerable design challenge—and one that is of critical importance if we’re to achieve widespread adoption of this promising technology.

A personal interest in Xapo

While evaluating bitcoin storage options, I created an account at Xapo, but soon afterwards switched to another product. I didn’t give much thought to why I switched; something just didn’t feel quite “right” about the Xapo product.

Then I happened to read the book, “Digital Gold”, by Nathaniel Popper. In his telling of the history of bitcoin, we’re introduced to Wences Casares, an Argentinean entrepreneur and the founder of Xapo. I so related to the life experiences, frugal disposition and passions of Wences, that I finished the book thinking that if I could choose to work with anyone in the bitcoin industry, it would be with him.

And that led me to think deeper about why his product Xapo didn’t stick with me, and what I’d do to fix it.

In the rest of this article, I’ll retrace my onboarding experience with Xapo, highlighting the frictions and confusions I felt along the way, and I’ll conclude with thoughts on the approach I’d take to addressing those problems.

The reader will notice that the article grows harsh in tone, and my fear is that it might come across as offensive. But just before editing all that out, I realized that the growing harshness is a direct reflection of the growing frustration I felt trying to get to know the product. And since that ultimately led me to leave Xapo, I decided it was an important ingredient to keep in the article.

So you’ve landed at Xapo

When you first land at Xapo, you’re greeted with the following message:

My very first thought was that the word “most” must be missing, i.e. that this message was supposed to have read, “The world’s most secure bitcoin wallet”. That’s a minor detail, but important in the sense that my very first cognitive experience with the product is a tiny bit of confusion.

Moving on, this first screen immediately refers to “cold storage” and “multi-signature” technologies. These are concepts that are unlikely to be commonly understood, and as such represents the first potential point of friction in terms of converting a new customer. If I were a new bitcoin user, still grappling with the concept of a “bitcoin wallet”, I think I’d feel unsure whether this product is or isn’t relevant to me.

Still feeling unsure about this product, I’m probably more likely to click “Start tour”, than to directly create an account.

Starting the tour, I’m dropped straight into the the topic of “offline encrypted servers”, that are “never connected to the internet”. Remember, this is the second screen I see as a potential new Xapo customer, and possibly even a new bitcoin user. I still don’t really know what the product is, but I’m launched into a presentation of how its security is implemented.

In that context, some questions a new bitcoin user might have:

If my bitcoins are offline, does that mean I can’t use them?
Why are the servers “never connected to the internet”?

(I know the answers to these questions, but I don’t expect the non-technical bitcoin user would.)

Clicking next…

I’m on screen number three, and I’m looking at “Wave-blocking Faraday cages”. I’m afraid a lot of people might return to their Google search at this point.

But for those who continue…

Screen number four talks about storing my bitcoins in Switzerland. A new bitcoin user might wonder if that’s even legal, vaguely recalling stories about Americans getting in trouble for having money there. And is the length of the access column really relevant to my decision to use this product?

We continue, just to finish the tour…

Now we’re on a page that gives the visual impression that we’re floating in space—complete with moving stars in the background—and boasting that Xapo has raised $40 million. This is the last screen in the product tour, and it’s the screen least related to the product.

At this point, I’ve finished the tour, but I feel I know even less about the product than I did at the beginning. I certainly am left with the impression that Xapo take security seriously, but I still don’t know exactly what Xapo is or whether it’s relevant to me.

The tour didn’t work. Let’s try navigating around.

Let’s look at the Xapo navigation options. We find six items that are treated equally from a visual design point of view:

An “about” area, where I hope I can learn more about what this product actually is.
Two “product” areas, for the wallet and the vault.
One “contextual” area, Institutions. I’m an individual, so I guess I should skip that one.
A functional area, “login”. I’ll also skip that for the moment.
And a hamburger menu, which, although it can have its place, is known to be the junk drawer of navigation controls, as you have no idea what to expect there.

So here’s the About page:

Reading this, I’m now thinking that the product is somehow a combination of a bitcoin wallet and a vault, perhaps not exposed to the risks I’ve read about with other online wallets. That sounds pretty good, and I find myself wanting to learn more about how that works.

But to learn more, it looks like I’ll need to tap the pulsating “down arrow”, because the designers felt that before understanding more about the product, I’m more likely to want to read—again—about the company’s investors.

So I click the down arrow, expecting to be taken somewhere where I can learn more about the product, but instead, all that happens is that I jump straight to that same message about the investors.

Let’s just create an account

If I can’t understand the product from the marketing site, maybe it’ll all make sense once I create an account. After doing that and logging in, I see three equal navigation items—xapo, wallet and vault. (And I find myself wondering why they’re all displayed in lower case, since at least Xapo has until now been consistently capitalized.)

So I click to access the “wallet”.

In the WALLET (now all capitalized), and I see a credit-card shaped block with a gear and a large “X” in the middle. I have no idea how to interpret the meaning of the big “X”? Is there something missing? Did I do something wrong?

Conceptually, “My Address” is information, while “Transfer” and “Send” are actions, and so they shouldn’t be treated identically in the visual UI. Here I find myself wondering what the difference is between “transferring” and “sending”.

Let’s try clicking on the gear icon:

This feels a bit overwhelming, and now I’m even more confused:

I still don’t know why I’m looking at an “X”. Should I email support about that?
Apparently this is the wallet I’ll use to send “micropayments” through “Twitter and third-party apps”. What if I want to send payments that are not “micro”? And what’s a “third party app”?
There’s no contextual help information around the concepts of “Who can access this wallet?” What does it even mean to “invite someone to my wallet”? Why should anyone other than me have access?

At this point I’m thinking, “OK, I was just looking for a place to store my bitcoins, but this thing looks waaaaaay too complicated for my needs.”

Let’s try the “vault”:

Instead of a black card used in the wallet, the vault is represented by a green card with a “V”. What does “V” mean—“Vault”? But if that were the case, shouldn’t the wallet have displayed a “W” instead of an “X”. And what are those three vertical white bars supposed to mean?

Say I want to transfer bitcoins into or out of the vault. Here’s what that looks like:

This UI gives the impression I’m transfering from my black “X” (different typeface now) to my green “V” (with three vertical lines). And it looks like the black wallet’s balance is in bitcoin (BTC), while the vault’s balance is in US Dollars (USD)?

And for some reason, whereas everywhere else in the site the submit buttons span the width of the window, here it’s shorter.

I believe it was around now, when I decided to just switch to another product. All of these conceptual and UI friction points caused me to feel insecure in using the product, and I also had a lingering suspicion that the product wasn’t really even intended for me.

Miscellaneous issues

I observered a number of other, minor design and copy quibbles at the website, none of which were show-stoppers, but all of which compound in terms of experience and impression.

I think the website needs some tightening and editing of the copy. For example, when you say, “Secure bitcoin storage is what we do best,” the first thing that comes to my mind is, “Everything else we do, we do worse.” Something like, “We’re the industry leader in secure bitcoin storage” might be better.

Here’s a layout issue, in which you can’t read the white text against the white background.

And here’s some poor attention to detail. Margin spacing is off. Font size doesn’t make sense with respect to the rest of the site.

Redesigning the product

The design of a product like Xapo has to both bridge the conceptual gap between people’s existing mental models of currency storage, security and use, and the realities associated with a complex system like bitcoin. And it has to do that within the context of a product that’s engaging, confidence-inspiring and easy to use.

But to design Xapo, specifically, would require an understanding of the business priorities of the company, which we don’t currently have. For example, we don’t know the relative importance of providing services to individuals vs institutions. (Xapo was recently announced to be the custodian for a new Bitcoin ETF traded on the stock market.)

So while a Xapo redesign is beyond the scope of this article, we can at least identify some likely objectives.

Let’s communciate what the product is, why you need it, and why you should choose Xapo long before getting into the implementation details of encrypted servers and 100 meter bunkers. Xapo are the best at security, but security is not the product.
A considerable conceptual challenge is helping the user understand why they would need both hot and cold wallets. Savings vs checking accounts comes to mind as an analogy, but falls short. (Perhaps we could even discover a way to present the wallet and vault as integral components of a single product, instead of two separate things?)
Let’s ensure that the process of signing up, creating a wallet, getting bitcoins into the wallet, and then understanding that we might want some of those bitcoins put into cold storage, is friction-free in concept and workflow.
Let’s introduce the secondary concepts around the product—multi-signatures, buying bitcoins, etc.—only after we’re sure users understand the core product.
Let’s divert the heavy stuff to the institutions—e.g. our $40 million dollar funding, our A-level advisors, our bunkers in Switzerland. It’s those who will have the time and interest in all that before making a decision.
Let’s make sure individuals know that using Xapo is free.
Let’s make the user experience engaging and reassuring. (The dark theme of the current product feels somehow omninous.)

Finally, let’s keep in mind that as early adopters, we’re participating in a historic process of transitioning people into an exciting but unfamiliar new world. Ultimately, after using the product, we want the user to feel better about entering the bitcoin economy than before they joined.

It’s a big challenge, indeed, but an exciting and worthwhile one to take on, since as product designers we have a huge opportunity and role to play in helping bitcoin succeed!

Managing customer relations on the Mac with Daylite and Direct Mail

2013-03-22T00:00:00+00:00

To help spread the word about the recent launch of Rego—an iPhone app for bookmarking locations—we wanted to send an email announcement to our contacts. We use two Mac OS X applications—Daylite, a customer relationship management (CRM) tool and Direct Mail, an emailing tool—which together allow us to segment and execute such announcements more effectively.

This article introduces these tools and describes how we use them.

Daylite

Daylite is a powerful, multi-user CRM for the Mac, and one that we’ve been using for close to 15 years. It provides integrated management of people, companies, opportunities, projects, and tasks.

In Makalu, we primarily use Daylite to keep track of people and companies, and their relationships to opportunities and projects. (For project management itself, we use Basecamp from 37signals.) Since this article describes how we use Daylite, it only scratches the surface of everything the tool can do.

Daylite architecture

Daylite runs as a server/client system. I have the server running on a home iMac and serving clients running on a MacBook Air, an iPhone 5 and an iPad mini.

The Daylite clients are smart enough to detect whether they need to connect to the server over the local network, or over the internet. Connecting over the internet obviously requires a fixed hostname, and we use a dynamic DNS provider for that. The Daylite server will automatically configure modern routers to provide the necessary external access.

The Daylite clients maintain a local copy of the server database and periodically sync themselves. So everything works very fast—online or offline.

An important component of the Daylite architecture is the Daylite Mail Assistant (DMA)—a plug-in for Apple Mail that integrates with the Daylite client—allowing you to create new contacts, companies, opportunities, projects and tasks directly from within Mail. In addition, DMA allows you to link important messages directly to those objects in Daylite.

In this screenshot, you can see I’ve linked this email to my contact Alex Bendiken, as well as our MLK Maintenance project.

(If I wanted to, I could also create a delegated task for Alex, and set a reminder for myself to follow up later—but again, we mostly use Basecamp, rather than Daylite, for project management.)

Classifying contacts by keyword

Daylite allows you to add any number of keywords to your contacts. These are like tags, and you’re free to define and use them as you like.

In Makalu, we’ve decided to classify our contacts primarily by three different groups of keywords — Context, Role and Relationship.

Let’s take a look at these:

Context. Our company does client work, and we also sell products like RaceSplitter, Rego and my Money for Something book. We’ve created a set of keywords to help us associate our contacts with each of these business contexts. (And, as you can imagine, some of our contacts are associated to several contexts.)
Role. We also need to distinguish in what role a contact exists. Is the person a customer, an applicant, or perhaps a partner.
Relationship. Perhaps most important, we need to know what kind of relationship we have with the person, and for that we’ve defined five.

Relationships are important, so let’s look at those in more detail.

Family is obvious.
Friend is probably obvious as well. Among the thousands of contacts I have, only about 120 are classified as friends.
Personal might need some explanation. A personal relationship isn’t quite a friend, but if you asked them, “Do you know Matt Henderson?” they would immediately say yes.
Acquaintance is someone with whom we’ve had a conversation in the past.
Unknown means we (for whatever reason) have them as a contact, but have never had a conversation with them (perhaps they were copied on some client communication to us).

Why is relationship so important? Mostly for segmenting our announcements, since you don’t want to send a close friend an email that says, “Hi there, my name is Matt Henderson…”

Filtering and segmenting

Daylite allows you to segment or filter your contacts through smart filters. If I need to quickly identify the RaceSplitter customers with whom we have an acquaintance relationship, it’s as simple as this:

And we can get much more complex! Say I want to identify all my contacts, excluding friends, family, personal and those I’ve tagged “A-List” and “Influential”. And say I want to exclude our competitors, my Dydra contacts, those people I came into contact with during the Catalog Choice project, and those people who commented on my Telefonica and Vodafone blog articles.

All that would look something like this:

Daylite’s ability to include sub-groups of filter criteria in the construction of smart filters basically removes all limits to the scope of possible segmentation.

Once I’ve filtered my contacts, I’ll add those people to Daylite Group objects, like these I created for our Rego announcement campaign.

Why use Groups? Because as we’ll see in the next section, Groups are the link between Daylite and our emailing tool—Direct Mail. Also in the next section, we’ll see why I prefixed the Group names with numbers.

Direct Mail

Direct Mail is a bulk-emailing tool for the Mac that integrates with Daylite. Like Daylite, Direct Mail is an established product that’s been on the market for many years.

And as with Daylite, this article will hardly scratch the surface of everything Direct Mail can do. It provides extensive capabilities for importing and validating addresses, and extensive support for message creation, allowing both text and HTML, and even the import of templates from popular online services like MailChimp and Campaign Monitor. It provides token substitution in messages (with fallback), and will even tell you how likely your message is to get caught in spam filters.

Although it can send outgoing emails through your own server, Direct Mail really shines when you send mail through their own hosted service, as that provides you with scheduled delivery, reporting and subscription management. You buy credits through the app, at about $0.01 per email.

So here’s how we use Direct Mail.

Serial, segmented mailing

In announcing Rego, I wanted to send different emails to different types of contacts. For people I know well and have a close relationship, I don’t mind asking for a favor to help us promote the app. For people I don’t know so well, I might just want to tell them about product and leave it at that.

So being able to segment is important, and we’ve seen how to do that with Daylite. Now we’ll look at the Direct Mail side of the setup.

From this screenshot, you can see that I’ve created a Direct Mail project document, called “Rego Announcement”.

In that document, I’ve created one address list corresponding to each of the Rego “Groups” I created in Daylite. Direct Mail maintains a link from its group to the Daylite group—allowing me to re-sync at any time, and allowing Direct Mail to link sent emails back to those corresponding contacts in Daylite.

Avoiding multiple mailings

It’s quite likely that some of my contacts will be found in multiple Rego Groups within Daylite. For example, some of our beta testers also signed up on the Rego website to be notified about the launch.

I want to ensure that we only announce Rego once per contact, and that’s the reason for adding a numeric prefix to my Group names.

In the above example, we first announced Rego to our beta testers, and then converted that Group to a Blacklisted group, to ensure that when emailing our Signups, none of our beta testers would additionally receive that email.

Then we announced to the people invited to the beta, but who didn’t ultimately participate. To do that, we emailed the “Beta Invites” group, while blacklisting the “Signups” and “Beta Testers”.

And so on through all our groups, ultimately emailing the largest group, our “Acquaintances”.

Make sense? It’s pretty cool!

Reporting

Direct Mail provides extensive delivery and interaction reporting and statistics through a Mac app, as well as through iOS reporting apps running on the iPhone and iPad.

Hope you enjoyed the article!

And there you have it. That’s how we use the powerful combination of Daylite and Direct Mail to manage our contacts and communications in Makalu Interactive. If you have any questions, don’t hesitate to contact us!

Getting ready for Rego

2013-03-01T00:00:00+00:00

We’re in the final week of beta testing prior to launching Rego, Makalu’s second product for the iPhone. I wanted to share with you a few reflections on the experience of getting here.

Simple products are hard

We’ll post more about this after launch, including a video of all the UI revisions we’ve made, but once again we find ourselves profoundly intrigued by how difficult it is to create a great—simple, clear & elegant—user interface model.

As always, we found that a “great” model is rarely pre-conceived; rather, it’s discovered through lots and lots of iteration. When we post the video, we think you’ll be amazed at how many iterations a simple little app like Rego can experience!

Lessons learned

What makes Rego different is that it’s meant to be private. Unlike apps like Foursquare, you don’t have to worry that Rego’ing that wonderful little cafe you discovered is going to expose it to the rest of the world. Sure, you can share a place with a friend if you want—and we make it such that they can seamlessly import it into their own Rego—but it’s an explicit action the user has to take. By default, everything’s private.

Preparing for our beta, we innocently thought we’d do our testers a favor by pre-loading Rego with a number of already-captured places and moments.

Huge mistake!

Why? Because that simple little inclusion gave almost all our testers the impression that Rego was primarily for discovery and sharing, completely obscuring the most important aspect of Rego, it’s privacy. (One tester commented, that they found zero places captured near them. Of course—that’s the point!)

So that was a big lesson learned for us. We had been considering including one location—the Makalu office, where Rego was born—with the final 1.0 product, but having this beta experience behind us, we know that would be a bad, bad idea!

So instead, we’ll ship with some great blank slates.

Positioning

Our biggest struggle is positioning.

We consciously crafted Rego to be a general utility that would adapt to a broad range of personal needs related to location. I might use Rego to keep track of my favorite restaurants and cafes. A real estate agent might use Rego to capture prospects and sales locations. An archeologist might use Rego to capture and classify “finds”. A fisherman might use Rego to track their catches. A tour guide might use Rego to package up interesting places for their clients.

In that respect, Rego is a general utility that would likely be of interest to everybody.

Great, right? Well, actually it’s not.

We’ve found it surprisingly difficult to effectively communicate that “general utility” value proposition. When my wife saw me Rego’ing my favorite cafes, she lost interest—that’s irrelevant to her. She didn’t see past my usage to how the facilities of the app could be useful to her. And we’ve found the same reaction from many of our beta testers.

But something interesting happened last week.

My wife scheduled a family weekend trip to Paris and I immediately decided to use Rego to both plan the trip and then capture memories in the form of notes and photos while there.

I began by Googling for interesting attractions, restaurants, and things to do in Paris. I then created places in Rego for all the ones I wanted to visit and organized them into a collection called “Paris Trip”. (I even added some notes with opening times, addresses, and phone numbers and a couple photos to help set the context when I’m there.)

Looking at the resulting map, I could immediately see that our hotel was 5km from most of the attractions we wanted to visit (unfortunately, though, it was too late to cancel.) So I also Rego’d the closest metro points.

Then while traveling in Paris, I used Rego constantly—to see what the closest “next attraction” was and to capture our memories in photos and notes attached to the places we visited (both the ones we’d planned, and new ones we discovered and Rego’d while there.)

After returning home, I blogged about the trip and posted a few public Rego shares for some of the places we visited. When those shares are viewed on iPhones, they can be directly imported into Rego—useful for others planning a trip to Paris who might want to experience some of the places we enjoyed.

The reaction to this article from several people, including my wife, went something like this:

Oh, wow—now I get Rego! It's the ultimate app for planning and documenting travels. I want it, I want it, I want it!

Planning and journaling travels will probably be the most common use case for Rego, and where its value will shine the most. But that’s just one of an infinite number of usages—which presents us with a delimma: Should we position Rego as a general purpose utility, or should we position it as a travel app?

Our current inclination is to position it as a travel app, but we’re torn over potentially losing the broader general-purpose market. We’ll likely be doing some A/B testing to help answer this question.

Coming soon

We’re going to be submitting Rego to the App Store next week, the first of March, and expect it to be available about a week after that.

Rego will be a free download, limited to about 10 places. An in-app purchase of $2.99 will unlock it for unlimited usage.

We’re planning to run a launch sale of $0.99 for about a week, so if you’d like to be notified when it’s available just head over to the Rego site and sign up today!

Going off the Book

2012-12-02T00:00:00+00:00

In chess, there’s a moment when a game deviates (if it ever does) from a well known sequences of moves each player has memorized. They call this going “off book”. I first heard of this concept while listening to an episode of RadioLab and it struck me as an apt metaphor for modern software development. In programming we have a book of moves to choose from too. Variations of common choices that we all make over and over.

We open with the platform, or platforms, on which our software will run. This could be a desktop or mobile OS or even the web. We probably also need to decide on a minimum level of functionality we’ll require.

Pawn to iOS >= 5.1

We then often build upon this initial move by choosing a language. Like in chess, our options for the next move are limited by the choices we’ve already made. Even still, there are a huge number of options for developing web applications and even on iOS there are alternatives to Objective-C that we might consider.

Bishop to Objective-C 2.0

We could go “off book” here and write our application. And while this would be a novel approach it would probably not be a smart one. Instead we usually employ the help of an existing framework. By choosing a framework we allow the framework authors to make a series of decisions for us in exchange for not only a savings in effort but the benefit of the framework author’s experience.

Knight to Cocoa Touch

At this point our framework may provide us with the option of using pre-made templates or scaffolding to get started with. Xcode comes with templates for numerous application types and web frameworks such as Ruby on Rails or Django often come with a way to automatically generate a basic project structure to build upon.

Queen to Single View Application template

This is our opening. We have made our own choices but they are not unique to us. More than likely many others have made the exact same choices up to this point. It’s only once we go “off book” that things get exciting. From this point on the roads aren’t paved and we have only our own experience and creativity to rely on. Like chess, this is where the game becomes unpredictable and where, more importantly, it gets fun.

How many developers are, at this very moment, staring at a brand new Xcode project? How many have just generated a new Ruby on Rails application? Many of these projects will never see the light of day but any one of them could change the world. This is what keeps me excited about software development. The joy of creating something no one has ever seen before. The challenge of solving new problems. The thrill of going “off book”.

This article was reposted from my personal blog at A Developing Story.

About those unsolicited designs

2012-11-30T00:00:00+00:00

Whenever we do design, it’s to meet one or more objectives. Perhaps the objective is to be aesthetically pleasing. Perhaps it’s to increase conversion on a landing page. Perhaps it’s to minimize the errors made by the operator of a satellite control system.

And when we do design, it’s usually in the context of one or more constraints. Perhaps the design has to be completed within a week. Perhaps it has to be completed within a particular budget. Perhaps it has to be delivered on a particular platform or device, or implementable with a certain technology.

Considered in this way, it’s better to characterize design by the extent to which it meets its objectives within its constraints — i.e. by how effective it is.

So the better question is whether effective design can come out of an unsolicited activity?

Each objective and each constraint can be thought of a dimension which constrains the space in which effective design solutions exist. Consider three planes in space. Their intersection can at best be a single point; almost always, they won’t intersect, and instead will bound some space in-between. That’s the reason perfect solution almost never exists, and why design is actually an engineering activity involving trade-offs.

It’s the job of the designer to identify the space in which an effective solution can exist, and then to create a solution within it. It’s his job to solve the puzzle. The more objectives and constraints involved, the smaller that space will become; the more complex the puzzle is to solve.

So let’s return to the question of whether an effective design can come out of an unsolicited activity? The answer is that it depends on the complexity of the puzzle to be solved. Without the knowledge of the objectives and constraints that the inside designer learns through a professional engagement, the less likely the outside designer is to even know what the puzzle is, much less be in a position to solve it. The outside designer is left only in a position to infer what the puzzle may be, and only for those aspects of the product to which they’re exposed.

Could unsolicited design result in an effective concert announcement poster? Probably. Could unsolicited design result in an effective satellite control system user interface. Far more unlikely.

How to calculate your hourly rate

2012-11-27T00:00:00+00:00

This article describes how we determine our rates here at Makalu.

Start with the minimum

Regardless of how you plan to charge for your work—i.e. on a project basis (fixed-fee) or an hourly basis—the first step is to determine the minimum amount you need to earn per chargeable hour.

Available hours. Begin by computing the number of hours per year each of our staff will work, on average, taking into account public holidays (12 days, in Germany), vacation (30 days, in Germany) and weekends (104 days, on Earth). In Germany, that’s 219 working days per year, or 1,752 available working hours.
Chargeable hours. It’s important to recognize that not all of a person’s available time will end up being chargeable. People will sometimes be supporting bids, sometimes working on overestimated projects, sometimes idle, sometimes off sick, etc. In our case, we assumed a chargeability figure of about 70% (which turns out to be pretty consistent with the service industry as a whole). With that, we’re down to about 1,226 chargeable hours per year, per person.
Minimal hourly rate. To compute a minimum hourly rate, we need to divide the minimum revenue we need to make per person, by those 1,226 chargeable hours. The total minimum revenue equals our employment costs (salary, benefits, social security, etc.), all overhead expenses (office rent, support staff, marketing, accounting, legal, etc.), plus the minimum profit we want to make.

Example. In a hypothetical scenario in which a company’s staff costs, on average, $75,000 per year per person, with overheads equivalent to say 20% of employment costs, and wanting to make a 15% profit, the minimum hourly rate would be roughly $85/hour.

How did we get to that number?

Minimum Hourly Rate Calculation

(If you’d like a copy of this Soulver document, you can download it here)

That wasn’t the particular number in Makalu’s case back when we got started, but might seem a reasonable starting point today.

Adjusting to balance supply and demand

Now that we have a starting point, is that it? Not quite. We now need to adjust that rate to balance supply and demand.

Over time, as we produced good work for our customers (and through some lucky breaks!), we found ourselves with consistently more demands on our time than we had availability. It’s important to note, however, that doesn’t necessarily imply a higher level of chargeability as all the elements relating to that 70% are usually still applicable.

As is natural in free markets, prices adjust in order to balance supply and demand, and so we began to slowly increase our hourly rate, in order to alleviate the excess demand. Some companies would have just ramped up their staff count. In Makalu, however, we place far greater importance on maintaining our ability to produce great work and deliver measurable value, and that means only hiring great people. We simply couldn’t find legions of great people; we’ve been lucky to find one per year!

An interesting consequence of increasing our hourly rate, is that the customers that were left tended to be exactly the type of customers we’ve always wanted to work for—they appreciate high quality, demand real value and are doing interesting things!

Reinventing the investment calculator

2012-10-03T00:00:00+00:00

The Challenge

Make an online investment calculator that helps readers of Money for Something answer questions like:

How much do I need to save each month to have a certain amount of money at a certain time in the future?
If I’m saving this much per month, and earning that rate of return, how long will it take to accumulate one million dollars?
If I increase my monthly savings, how will that affect my savings in the future, and the amount of income it’ll provide?
How sensitive is the final amount to the savings rate? or to the amount of time?

The Strategy

We began by looking at some existing calculators:

While these might be adequate for their target audiences, it was obvious they didn’t meet our goals. Want to change a value? Well, simply click into the field, switch to using the keyboard, clear the old value, type the new value, and submit. Want to compare two calculations? Better write down the previous result before you make a change.

One of them even tries to be extra helpful by offering options to save more by giving up daily expenses, like coffee, restaurants, pizza, etc. But who really does that? There’s no need to give up coffee and pizza for the next 25 years in order to achieve financial independence.

We knew our calculator needed to be friendlier and much more interactive than anything else we’d seen. You ought to be able to just jump in and start using it right away. Your very first interaction should have an immediate effect on the final result, which hopefully piques your curiosity and leads you to try out more “what ifs”.

To achieve that, there should be no forms to fill in, it should be easy to adjust the values, and most importantly, it would need to update live.

The Interaction Design

Our first design challenge was to decide what to focus on. The calculation is based on a number of variables: rate of return, initial balance, monthly savings, inflation, annual savings increase, etc. Obviously we can’t just ask people to fill in all of those. Even having read Matt’s book, I wouldn’t have any idea where to start. So we needed to narrow down the options.

Early design explorations

After some back and forth we decided to focus on just three variables:

Starting balance. How much do you have saved right now?
Monthly savings. How much can you afford to save per month?
Years to invest. When do you want to retire?

What these variables have in common is that they’re all unique to your circumstances. Do you already have some savings? Adjust the starting balance accordingly. You’re making $5k per month? You probably want to be saving at least $500. You’re 25 years old? Maybe you want to retire when you’re 50 years old.

It’s not that the rest of the variables, like rate of return and commissions, are any less important, but you just have much less influence over them. Our guess is that most people will be fine with the default values. That being said, it is useful to see how a different rate of return influences the calculations, so these values should still be editable.

When you add up all of those variables, and run them through some formulas, what you end up with is a final balance in dollars. However, the dollar amount by itself is not terribly useful. One million dollars is a nice round number—and who doesn’t want to be a millionaire—but is it enough to retire on? It’s difficult to put into perspective without some more context.

Thankfully, Matt’s book introduces a rule of thumb known as the “4% rule”, which states that you can annually withdraw 4% of your savings for the rest of your life, without risking to run out of money. That makes it easy to compare the final balance to your current income and see if it’s even in the ballpark.

Another thing we wanted to emphasize was the power of compounding interest. Given sufficient time, the amount you make from interest will far outgrow the money you’ve put in. Just a couple years can make a surprisingly big difference. We chose a stacked area graph to illustrate how this proportion changes over time. It nicely contrasts the linear growth of the savings with the hockey stick curve of the earnings.

More design explorations

At this point we had the basic building blocks: a chart, basic variables, advanced variables, and a summary showing both the final balance and 4% rule. Our next challenge was figuring out the easiest way to edit the variables.

The obvious solution is to use standard text fields—just like every other calculator on the web. While flexible and easy to implement, they’re cumbersome to actually use. Not to mention we’d have to deal with formatting differences, validations, and whatnot. Not ideal.

How about sliders? They’re easier to adjust, that’s for sure, but they also implicitly suggest a range of values. The amount I can invest per month should in no way be related to what the slider’s maximum value happens to be configured to. It’s a potential point of confusion, so we continued looking for something else.

We need something that’s unconstrained, as if you were typing the values directly, but that’s easy to change, just like dragging a slider.

Bret Victor to the rescue. If you’re not familiar with Bret’s work, you should definitely go read some of his essays. Impressive stuff. His Tangle Javascript library lets you change variables in text, simply by dragging them directly in context. It gives us the convenience of sliders, with the flexibility of input fields (minus the hassle). Perfect.

Well, perfect except that people in general are not accustomed to dragging text, so we need to somehow communicate that they can do that. Once you get a hang of it, though, it’s super convenient to play with the values. In this case we were willing to sacrifice a bit of discoverability for increased usability. (It did end up biting us though. Keep reading…)

The UI & Visual Design

If you look at the design explorations above, you’ll notice that we had actually gotten ahead of ourselves by adding styling to what was supposed to be wireframes. So we took a couple steps back, stripped all the styling and made an inventory of the content.

Here’s an abridged version of the thought process that followed:

Now that everything is laid out, it’s easy to focus on what matters and start grouping things together. Try to resist the temptation to make things symmetrical, or to align them perfectly, or to add something new, and instead look for inherent connections in the content.

Let’s start by grouping the main variables together. They should probably be at the top, since they’re the first thing you’ll want to tweak. The chart, final balance, and 4% rule are all part of the result, so let’s bunch those together as well. And for now, let’s just put the “advanced options” at the bottom.

That’s a start. But the result column blends in with the adjustable values at the top. Let’s try differentiating them through contrast.

Better. Except that now the whole thing looks top-heavy. It also lacks a clear flow—you can adjust the middle part from the top and the bottom. Let’s group the adjustable variables together at the bottom, which should hopefully solve both issues.

OK, things are starting to look more balanced. That right column with the final amount just doesn’t sit right, though. It’s taking up way too much space to show so little information. Space that could be used for a bigger chart. Not only that, but its alignment with the years could be confusing.

Where else could we put it? See that big empty space in the upper-left corner of the chart? Doesn’t it look like the results block would fit perfectly there? Let’s give it a shot…

That’s it. We’re left with two distinct units: one for displaying the results, and another one for adjusting the values. Now it’s just a matter of cleaning up the visuals, amping up the contrast, and adding some color.

In addition to the visuals, we made a few other refinements in this final iteration:

We added arrows to indicate that the values are draggable.
We turned the chart legend into supporting content, which not only better integrates it with the rest of the design, but also increases its usefulness.
We turned the 4% rule into a self-explanatory sentence, therefore avoiding having to add a separate help link for it.
We de-emphasized the advanced variables by turning it into a footnote.

And we’re done!

Or so we thought. Here are some things we changed shortly after launching the calculator:

The arrows on the adjustable values misled people to think you could click on them. We changed them to a more explicit textual help. Not quite as elegant, but infinitely clearer.
From the start we had wanted to add the ability to make comparisons, but were unable to make it clear and easy to use. Then, right after launch, we had an epiphany. What if we just displayed the change from the previous balance whenever you make an adjustment? Turns out that was sufficient for the majority of cases we wanted to support.
We also added some example scenarios, to give people ideas for using the calculator.

The Takeaway

The calculator was designed and built almost entirely by Marcus Andersson, our new intern from Sweden, with a little guidance from yours truly. Marcus is studying mobile development at Hyper Island, but wants to learn more about design and front-end development, so this was the perfect bite-size project for him to get started.

In the process he improved his Javascript skills and learned CoffeeScript, SCSS, and HAML (yes, we like abstractions). He also got a crash course to how we approach design at Makalu. Here are some of his lessons learned:

Start with the content first. Be sure to understand what you’re designing and always use real content. Before adding anything extra, look for connections and opportunities inherent to what you already have.
Iterate and test. Test your designs frequently against the defined goals and keep experimenting with alternative solutions. When you think you have the perfect design, push further, try other approaches and be open to change.
Re-evaluate your assumptions. If you feel stuck with the design, take a step back and try questioning the constraints and assumptions that led to where you are.

We think the end result is by far the easiest-to-use investment calculator anywhere. Give it a go and let us know what you think.

Communicating with Blocks in Objective-C

2012-09-03T00:00:00+00:00

Let’s talk about blocks.

One area where I’ve personally seen a lot of benefit from using blocks is in setting up communication between separate systems. This could be communication between an app and a web service or between separate concerns within a single app. Communication with blocks helps maintain a high level of encapsulation while keeping your code readable and concise.

Traditionally, we might set up communication between two objects using a delegate. Delegates are used througout Cocoa and Cocoa Touch to great effect and they’re virtually impossible to avoid. In iOS, the application delegate is one of the first objects we interact with. Delegates work well when two objects need to have an ongoing or broad relationship and the UITableView delegate is a great example of this.

In other cases we might just want to be able to pass a little information around between objects without them necessarily knowing that much about each other. While we can get by defining a delegate protocol, implementing the delegate methods on our object and assigning the delegate to a property, using blocks we can accomplish the same thing while avoiding formal protocols and keeping the related code closer together.

Let’s say we want to build an app that fetches and displays stock quotes. Because we’re good little programmers we’ve decided to separate, or encapsuate, the logic that actually communicates with whatever web service we’re using and provides a common interface or API for the rest of our app to use.

If you’re new to this stuff (or if you use PHP) you might wonder why we would do this. Well for one, in the future we might want, or need, to switch the service that provides our stock quotes. If we wrote directly to the original service’s API in our app and the new service is not compatible with the original one we would need to update our application in any number of different places to make this change. But with the service API safely abstracted away behind an internal API of our own devising we would need only to modify one part of the app. This is called Separation of Concerns, and it’s a wonderful thing.

Let’s assume we’ve got our Xcode project set up. You can even download the complete project from Github if you want. Why don’t we first define the class that will handle all communication with the stock API we’ll be using. This class will provide the internal API that our application will interact with.

Note: For this example I’m using the undocumented but public Yahoo! stock quote API the details of which are beyond this post but available elsewhere on the internet.

//  SPFPriceFetcher.h

#import <Foundation/Foundation.h>

typedef void (^SPFQuoteRequestCompleteBlock) (BOOL wasSuccessful, NSDecimalNumber *price);

@interface SPFPriceFetcher : NSObject

- (void)requestQuoteForSymbol:(NSString *)symbol
                 withCallback:(SPFQuoteRequestCompleteBlock)callback;

@end

Very simple. Just one method that takes a stock symbol and a callback block. As you can see here I’ve used a typedef to define the callback. In many ways this is like defining an informal protocol. It’s not necessary and you can define the block inline with the method but in this case I think it aids in readability and it can be helpful when defining a callback as we’ll see later.

Here’s the implementation of our PriceFetcher class.

//  SPFPriceFetcher.m

#import "SPFPriceFetcher.h"
#import "JCDHTTPConnection.h"

// Yahoo stock quote API
// Example: http://download.finance.yahoo.com/d/quotes.csv?s=GOOG&f=l1
#define kYahooStockQuoteAPIURL @"http://download.finance.yahoo.com/d/quotes.csv"
#define kYahooStockQuoteAPIFormatString @"l1"

@implementation SPFPriceFetcher

- (void)requestQuoteForSymbol:(NSString *)symbol withCallback:(SPFQuoteRequestCompleteBlock)callback
{
    NSURL *url = [NSURL URLWithString:[NSString stringWithFormat:@"%@?s=%@&f=%@",
                                       kYahooStockQuoteAPIURL,
                                       symbol,
                                       kYahooStockQuoteAPIFormatString]];

    NSURLRequest *request = [NSURLRequest requestWithURL:url];

    JCDHTTPConnection *connection = [[JCDHTTPConnection alloc] initWithRequest:request];
    [connection executeRequestOnSuccess:
     ^(NSHTTPURLResponse *response, NSString *bodyString) {
         if (response.statusCode == 200) {
             NSDecimalNumber *price = [NSDecimalNumber decimalNumberWithString:bodyString];
             callback(YES, price);
         } else {
             callback(NO, nil);
         }
     } failure:^(NSHTTPURLResponse *response, NSString *bodyString, NSError *error) {
         callback(NO, nil);
     } didSendData:nil];
}

@end

You may notice that I’m keeping this block love-in going strong here by using my JCDHTTPConnection class which itself provides a block-based API for making HTTP requests using NSURLConnection. Calling blocks from within other blocks can be very powerful and allows you to chain callbacks which is also neat. I’m not going to go into all of this but basically we’re just making a simple GET request to the API url and passing in the stock symbol as a parameter. When our request completes we check to make sure it was successful and execute the callback block we’ve been passed with a BOOL indicating whether we able to fetch the price and, if so, the price we fetched.

With our API proxy in place we can now look at how our application code might use this class. Our app’s only view controller (SPFViewController) has a single action that’s connected to the “Get Price” button in our UI. This action defines a callback block and then uses an instance of the SPFPriceFetcher class (that we lazily instantiate) to make the actual request. The callback that we pass in only needs to check if we were successful and update the UI accordingly.

- (IBAction)getPrice:(id)sender {
    SPFQuoteRequestCompleteBlock callback = ^(BOOL wasSuccessful, NSDecimalNumber *price) {
        if (wasSuccessful) {
            self.priceLabel.text = [NSString stringWithFormat:@"Latest price: $%@", [price stringValue]];
        } else {
            self.priceLabel.text = @"Unable to fetch price. Try again.";
        }
    };

    [self.quoter requestQuoteForSymbol:self.stockSymbolTextField.text
                          withCallback:callback];
}

With our application structured in this way we can easily change the internal workings of our PriceFetcher class without having to modify any other code. And because we’ve used blocks to implement our API we have the flexiblity to define our callbacks inline, ahead of time, or even pass them around or store them in instance variables.

If you haven’t already you can download the complete project from Github.

I can only imagine we’ll be seeing more Apple APIs that use blocks in the future. Delegate-based APIs like NSURLConnection are clumsy and begging for a more modern interface. As an exercise, try rewriting our PriceFetcher class using NSURLConnection without JCDHTTPConnection and see how much code it takes (sure you can cheat by using stringWithContentsOfURL but what if we need to make a POST request?). Blocks are a great addition to the Objective C language and they can help us all write better, and less, code.

This article was reposted from my personal blog at A Developing Story.

Design for great customer support

2012-05-31T00:00:00+00:00

One thing the experience with RaceSplitter has clearly taught us at Makalu Interactive is that customers absolutely love getting personalized service from somebody who knows the product inside and out. And that love translates to loyalty, retention, word-of-mouth marketing and all sorts of goodness.

“Support is awesome—quick, personal and great. Multiple messages answering all questions asked with helpful hints. Not a form letter as with some apps I have seen. These guys know their app and take the time to support their users.”
—recent five-star review in the App Store

Obviously nobody’s in a better position to provide this level of customer support than the product development team. But as a product becomes popular, and you have more and more customers, the problem of course is scaling that support. If your development team is answering hundreds of mails a day, they’re not going to be doing much development.

At some point, companies hire support staff, and not having quite the product insight the development team has, service tends to devolve into the land of boilerplate.

“Thanks so much for contacting us! We sincerely appreciate both your business, and your frustration! Have you tried restarting? I hope I’ve been of some help. Have a great weekend! Love, Your Friendly Support Agent.” (Please don’t reply directly to this email, as the account is not followed by humans.)

What can we do to avoid that fate? (Or at least avoid it for as long as possible?)

Empathetic design

Keep the product as simple as possible.
We iterate on the user interface to eliminate usage friction (all those tiny little points of “what next?” or “what just happened?” confusion)
Anticipate those “first moment” needs — the first-time a person visits the various sections of the website, the first time a customer returns to the website after having bought the app, the first time the customer launches the app and all the blank-slate versions of every functional screen.
Carefully craft the website copy and the text of our emails. We grab friends, ask them to read it, and watch their reaction.
Continually observe how the customers use the product, and enhance the experience to address common problems. (In the case of RaceSplitter, we automatically monitor their published results, looking for likely cases of mis-typed timing entries, and automatically send them a small email when we suspect it happened, and tell them how to recover.)
Get out in the field and use the product ourselves. (In the case of RaceSplitter, you can’t simulate the pressure of a real race in the comforts of an office!)

All these things work to minimize the support requests we receive — allowing us to grow our customer base, while still being able to provide personalized customer service in cases when they do reach out to us.

Making of the Catalog Choice iPhone App

2011-12-08T00:00:00+00:00

It's not every day that an opportunity presents itself to develop a product for an audience of **1.5 million people**. That’s exactly what happened recently at Makalu, as we were engaged to develop the iPhone component of Catalog Choice’s new suite of premium services.

And we can’t wait to tell you about it!

The background

In 2007, Makalu was engaged by The Ecology Center of Berkeley, California to design and build a website that would provide American consumers with an effective tool to combat the growing number of unwanted catalogs they receive in the mail. The website — CatalogChoice.org — was launched, and quickly received the attention of nearly every large media channel in the United States, including a focus spot on “Good Morning America”.

Within one year, the service signed up more than one million members.

When Catalog Choice members receive an unwanted catalog, they login to their account, search for the catalog they received, and register an “opt-out” request. At that point, the Catalog Choice system acts as a powerful agent on behalf of the consumer to get request processed by the sending merchant. In this way, the consumer saves the effort of having to interact with individual companies, and benefits from the effectiveness the influential service has in getting their requests honored.

Through use of Catalog Choice, consumers reduce clutter and simplify their lives. And on the collective scale of millions, the service is helping the environment by considerably reducing the natural resources used in the production of unwanted catalogs.

Re-engaging with our friends

After Catalog Choice’s first year, when it was clear that a market existed for the service, a dedicated non-profit was formed, at which point The Ecology Center and Makalu handed the project over to the team that was established to manage and operate the service moving forward.

Five years later, we’ve re-engaged with our friends at Catalog Choice to:

Redesign the website, harmonizing the contextual changes and features that have evolved over the past half-decade, and to
Design and develop an iPhone app, which is the first in a suite of premium products known as, MailStop.

We’ll first take a look at the website redesign, and then look at the iPhone app.

Catalog Choice website redesign

Over the years, the service has expanded beyond catalogs, allowing consumers to opt-out of all types of unwanted mail — everything from credit card offers, to phone books. In addition, the service has established special relationships with local communities and townships throughout the United States, which are reflected in various ways throughout the site. Accommodating these changes, along with the introduction of a set of premium services, necessitated a fresh look at the overall site architecture and design.

The service is preparing to launch the new design, which so far has addressed the home page, and the purchase workflow related to the new MailStop products. We focused on simplification, higher sign-up conversion, and clearer communication of the service’s message.

We’re thrilled to show you three sneak-peek screenshots of the new look:

We’re really happy about the design, and looking forward to seeing its launch, and extended implementation throughout the site.

The MailStop iPhone App

The MailStop suite was conceived as a set of premium add-on services that both extend the ways in which consumers can be protected, and make using the existed Catalog Choice services even easier.

In that regard, Makalu was engaged to design and develop an iPhone app that saves consumers the effort of even having to login to the website. Having purchased opt-out credits (as an in-app purchase), users of the service can simply capture the relevant information related to their unwanted mail in images, and submit them directly to the service. Catalog Choice takes it from there.

With the MailStop iPhone app, it couldn’t be easier to opt-out of unwanted mail!

The design process

The experience of RaceSplitter and Rebalance (still ongoing) has taught us that it’s far more time consuming and expensive to change app code than design mockups (when, for example, you realized you’ve gone in a wrong direction), and so with the MailStop app, we went much further into the UI design than we have in the past, before starting the development.

The results were good. We found that a reasonable level of discussion and review were, in fact, possible around just a set of mock-ups, as opposed to playing with a working prototype. On the other hand, it wasn’t perfect. Although it was possible to satisfy all the requirements and constraints in abstract design, once the product came to life in the form of a prototype, we realized that no matter how careful you are, you can never completely appreciate the subtle interactions and frictions that make themselves apparent when actually using a product.

For example, during the design process we iterated six times on the workflow in which a user captures “up to” three images to capture three critical pieces of information (the catalog name, mailing label, and merchant data.) How do you efficiently communicate to the user that they can take up to three images, but that one is often sufficient? Given that they are to capture three pieces of information, the risk is that they assume they must take three photos.

As you can see in our screenshots below, our solution feels more described than direct, and that’s an important disctinction. The designed solution works, but it’s not perfect. We’ll take the opportunity in version 2 to design something which feels more direct and intuitive, and better avoids the potential correlation in the user’s mind of the number of photos available, and the number of information pieces we need.

The design and development process, however, was definitely an improvement over the experience we had with RaceSplitter (in which we built prototypes too early). We’re pleased with the results, but we didn’t yet hit the sweet spot; and so there’s process improvements still to be discovered.

A visual tour of the app

And with that, we’d love to show you the app, with this 10-image tour.

Look interesting? Why not give it a try right now? It’s free, and available today on the App Store!

How to schedule focus

2011-11-23T00:00:00+00:00

For nearly a decade, we at Makalu have worked to consistently deliver real, objective value to our customers, and by external measures we’ve been successful. We built a website for Catalog Choice that registered a million users in its first year. We built a game for Google and Virgin America that Ogilvy & Mather pointed to as a reference for modern-day marketing. And we’ve increased signed up conversion, customer retention, and ultimately the bottom line for many more.

We seem to have done well, which is great, except for one thing — we’ve never been able to shake a nagging feeling of dissatisfaction. Although we’re doing good work by external standards, we know deep down that we’re not doing our best work, by our own standards.

Is it something we should just accept, or should we do something about it? In case others in our industry might share in this internal tension, I decided to put our thoughts into an article to share.

Doing great work

Doing really great work requires focus — getting in the zone, and staying there, uninterrupted, until you come to whatever milestone makes sense in the context (a wireframe, a mockup, a prototype iteration, or a blog article.) And, unfortunately, you can’t know in advance exactly how long it will take to get there. You might know it usually takes a day, but sometimes it takes three.

So to create great work, we need uninterrupted focus, for as long as it takes.

Running a services business

Customer engagements (even if you’re your own customer) introduces constraints that work contrary to producing ones best work.

The owner of a services company can, through policy, control some of these constraints. When talking with potential customers, you can communicate that your company’s mission is to do great work, and therefore you avoid certain things. In our case, that would include fixed-price projects, and projects involving severely limiting budgets or time contraints. We’ve done a good job sticking with this policy.

But what we haven’t been able to avoid, is the necessity of working on multiple projects in parallel.

Project concurrency to address idle time

All service projects involve idle time, such as when a customer reviews an iteration, or when a delay is introduced. We could try to forcibly manage flow by contract, but nobody likes that. Both customers and providers appreciate a process that allows projects to follow their natural dynamic, and reasonably accommodate the unforseen. So we accept that (sometimes unpredictable) idle time is part of our way of doing business.

So how can we address the cost impact (and profit loss) of idle time? Our approach has been to operate multiple projects in parallel, for a given team, in an effort to keep our resources busy. It doesn’t eliminate idle time, and it introduces its own challenges, but it’s the best approach we’ve found.

Of course, if we take on too many projects, we’ll end up the source of project delays, and we don’t want that. We’ve found, through experience, that things go well if we take on no more than two projects at a time, per team.

Effort scheduling

So we’re working on two projects, each of which has some current milestone that we’re working towards. How do we schedule our time?

We’ve tended to schedule our time weekly, by day — Monday (Project 1), Tuesday (Project 2), Wednesday (Project 1), Thursday (Project 1 & Project 2), Friday (Project 2) — taking into account, as best possible, the various needs of each project.

(Since we don’t know how long it takes to get to a milestone, and if we insist on providing at least a minimum level of quality, then a consequence of this planning is that we can’t tell Client 1, “We’ll finish XYZ by Monday night.” Instead, we can only say, “We’ll be working all day Monday, Wednesday and half of Thursday, and we think we might get to XYZ.”)

This loading (two projects at once) and planning strategy has worked well during the past few years — we haven’t gotten terribly behind on any project, we’re maintaining a consistently high ratio of chargeable/non-chargeable time, our customers have all been happy, and we’ve remained profitable.

But, there’s that darn elephant in the room.

At the end of the day, we just don’t feel satisfied. We try to soldier on, but it keeps popping up. We keep asking ourselves, “We only have one life to live. Are we really OK with not doing our best?”

A new approach — scheduling in blocks of a week

Analyzing things, we suspect that the focus (essential to great work) lost with daily (and sometimes mid-daily) context switches is just too consequential. Knowing that we’re switching context so frequently seems to create too strong a feeling of urgency, encourages taking shortcuts, and going with known patterns instead of pushing the envelope. It seems to lead to good enough.

To address this, we’re going to try experimenting with planning things in blocks of a week — i.e. Week 1 (Project 1), Week 2 (Project 2), and so on. We’re hoping that focus blocks in units of weeks will give us enough time to reflect and explore, allowing us to get deep enough to make the work great.

That’s the target, at least. I’m sure it’s going to prove easier said than done. Implementing this will imply both economic and scheduling concessions on the part of our customers. But, if it gets us closer to doing our very best work, maybe it’ll prove worth it — for both us, and our customers.

We’ll see, and I’ll report back.

We’re looking for a designer

2011-09-12T00:00:00+00:00

Who we are

Makalu Interactive is a small company that provides its clients with high quality design, development and consulting services. We regularly get to work on interesting projects for great companies like Google, YouTube, Virgin America and O’Reilly.

Recently, we’ve begun to produce our own products. Our long term goal is to sustain ourselves exclusively through products.

Our office is on the Mediterranean sea, in beautiful Marbella, Spain.

What we’re like

Quality of life is very important. At the end of our careers, we want look back on years of doing great work, creating real value, solving important problems, delighting people, and feeling we’ve done our best and have enjoyed ourselves. We’re very serious about that.

We believe if those are the priorities, everything else will fall into place. So far everything has.

Who we’re looking for

You’re someone who loves to design product interfaces, and has experience with web and mobile design. Although you feel you still have so much to learn, you know inside you’re really good at what you do.

Ideally, you like to build what you design, and are proficient in HTML and CSS (maybe even JavaScript.) You’re not afraid of technology.

You enjoy studying well designed products, like those from Apple. You like to think about the process of design, and try to figure out how to consistently produce great design. Your work is thoughtful, reasoned and justified; very little is arbitrary.

Characteristics that are likely important to you are humility, honesty, objectivity and authenticity.

About the job

We’d love to hire someone who can work in our office. But we’re also fine with remote working. If you’re based in Europe, at least we’d be in the same time zone.

Although this is a full time position, we’ll probably want to start with a couple of pilot projects, to make sure we’re right for each other.

How to apply

Along with your CV, send a letter to matt at makaluinc.com explaining why you’re interested in the position.

Minimum Viable Products

2011-07-31T00:00:00+00:00

Early in 2011, we at Makalu released our first product — “RaceSplitter,” an application for the iPhone that changes how organizers of sporting events time their races. Our aim for version 1.0 was to deliver a “minimum viable product”. This article discusses what that means to us.

Minimal product does not mean minimal implementation

Any organization that sets out to bring a product to market must decide what to build, and on that point it’s common to hear people speak of a “minimum viable product” — i.e. a product with the minimal functionality to deliver the core of the its value proposition.

Many organizations take this definition one step further, to include the minimum implementation of the minimum functionality, believing that — perhaps in the interest of time or costs — it’s acceptable to release a product that’s rough around the edges, and later improve on it (possibly depending on how well it’s accepted by the market).

We believe this is short-sighted, and reflects a flawed perception of the importance, even criticality, of the user experience in the success of any new product.

The case of RaceSplitter

After 200 man-hours of effort, we had a version of RaceSplitter which was minimally functional, in that it implemented all of the features we considered core to the product — you could create and configure a race, you could time a race, and you could export results.

But it wasn’t until we’d invested an additional 400 hours improving the user interface — fully two thirds of the overall development cost — that we felt we had a minimum viable product — i.e. a product that delivered the core functionality, and within an experience so delightful that the users would want to tell others about it.

Here’s a number of examples:

Reducing fundamental interface complexity. The user interaction model went through three fundamental revisions. Each revision reduced one complete level of hierarchy. The result was an interface providing access to the essential features, with far fewer clicks. Identifing potential reductions of hierarchy is as important as it is difficult, and requires a conscious effort not to get stuck in the current interface paradigm.
Making the user think less. The interaction of the timing model — i.e. how the user records the time when a racer passes by — went through several iterations until one was found that supported three modes of timing simultaneously: (1) single racer timing, (2) group timing (giving the same time to multiple racers), and (3) sub-group timing (giving the same time to a subset of a selected group of racers). By supporting all timing scenarios in a single interaction model, we avoid one user choice: “Which mode should I select?” That’s a lot of effort to reduce a single decision; but in the heat of a race, that can make the difference between successful and failed use of the product.
Reducing interface friction. We worked to identify momentary pauses occurring when users (and us) interacted with the app, and then made efforts to eliminate those UI friction points. For example, when changing a race from one start mode to another — e.g. from interval start to mass start — we inform the user what effect that’s going to have on the ordering of any racers already existing in the start list (giving them the chance to cancel the change). This contextual feedback eliminated that momentary, “Uh oh, how’s this going to affect things I’ve already done?” friction.

Iterate with high-fidelity prototypes

We found that these kinds of user experience refinements are best achieved through an iterative process of testing high-fidelity (working) prototypes of the application, and diligently seeking to identify points of friction.

You can identify friction by watching someone use the product for the first time, without a manual. For example, with RaceSplitter, when you ask them to create and run a race, and observe a smooth tap-tap-tap-tap-tap-done, you know you’re on the right path. But when you see tap-tap…hmmm…tap…oops…tap — you know further thinking and refinements are needed.

Costly, but worth it

This process of iterating with working prototypes is obviously costly. On the other hand, you simply can’t get this kind of deep insight by staring at static mockups, and imagining yourself using the app. We’re convinced that in the long run, the costlier development approach maximizes the possibility of the product ultimately succeeding in the marketplace.

In the case of RaceSplitter, our initial users absolutely loved the product. Time and again, we’ve received feedback along the lines of, “It’s so easy to use! With no instruction at all, I was able to time the entire event, edit a couple mis-entries, and publish the results online.” In fact, due to the enthusiasm (and blogging!) of a single early adopter in Norway, we’ve ended up selling nearly as many copies in that one small country as we have in the entire United States.

It’s your choice.

Shipping the minimal implementation of the minimum viable product can save money and get a product to market faster. But it increases the chances that your first users will think, “Nice idea. I’ll try to remember to check back someday.” — and then never return.

Quality execution takes longer and costs more, but ultimately leads to far better chances of success in the marketplace. And at the end of the day, that’s all that matters.

The Story of RaceSplitter

2011-03-17T00:00:00+00:00

This article was first featured on the blog at 37signals (a company which has long been a role model for us).

Makalu — history of a service provider

Since 2001, our small team at Makalu Interactive has provided web design and development services for clients around the world. We’ve been fortunate to work on some high-profile projects, including the original CatalogChoice.org site, which gained over one million users in its first year, and the interactive game anchoring the Google & Virgin America cross-marketing campaign, Day in the Cloud. (And as a side note, Sortfolio has proven to be an amazing source of high-quality leads for us.)

The itch to create for ourselves

Despite success in client work, we’ve always imagined that creating our own products would bring deeper satisfaction, and provide the opportunity to succeed beyond the linear function of available manpower. As a team of people passionate about great user experience — and having studied the companies that make them (like Apple) and the processes through which they are made — we’ve always been curious as to just what kind of product we would be capable of making.

We’ve always identified with 37signals. It was inspiring to watch a team of people that seemed so much like ourselves transition from a web design company (like ourselves) to a highly successful products company. We also enjoyed both Getting Real and REWORK, as they articulated a refreshing view and simple approach to many of the issues we struggled with. (It was no small satisfaction to later learn that a former employee of Makalu, Mike Rohde, would end up being the designer of the REWORK illustrations.)

Not only did we try to apply the ideas from Getting Real & REWORK to our client services business, we later found them particularly valuable when making our first steps in the direction of becoming products company.

Hello RaceSplitter

Last year, we were approached by a group of people associated with NENSA.net, FasterSkier.com and FlyingPointRoad.com, interested in having a timing app developed, for recording split times and providing relative racer position during nordic ski events. With European timing devices costing $500 and up, and the previously popular Palm app going the way of the PalmOS, it seemed natural that something should be built for the iPhone.

In certain nordic ski races, similar to cycling time trials, racers start individually or in waves, separated by a start time interval — say, 30 seconds. If you’re a coach on the course, timing racers as they pass by, it’s difficult to know who’s in the lead. Although it does other things, that’s the essential problem that app solves.

We accepted the project, and got to work. The app would be called RaceSplitter.

http://racesplitter.com

It soon became apparent that the app had the potential to be an ideal first product for Makalu. It passed both the “scratch your own itch” and “focus on what doesn’t change” tests. As both participants and observers in similar sports, we were deeply familiar with the application domain, and needed such an app ourselves. And unlike an app for, say, telling the world you’ve checked in at Starbucks, a sports timing device is something that should be as relevant in five years as it is today.

We put together a proposal, in which Makalu would acquire ownership of the app, with the client keeping a minority stake. Seeing our interest, not only in the app itself, but also in building a business around the product, they accepted our offer and RaceSplitter became Makalu’s first product.

As a client provider, one always hopes to give 100% to the client, but we’d be lying if we didn’t admit that becoming the app’s owner didn’t provoke a psychological change. This was the chance we’d been waiting for; to discover what we were truly capable of.

The complete user experience — attention to detail

We poured our hearts and abilities into the product. As believers that user experience extends to every way in which a product interfaces its users, we worked as hard on things like the pre-launch sign-up site, announcement emails, even the app icon, as we did on the app itself.

The RaceSplitter signup screen

The RaceSplitter website

As emphasized in REWORK, even though our 1.0 would be minimal in terms of features, it wouldn’t be half-assed; it’d be “at-home good”.

Launch — an international hit

The application launched, at $24.99, and within its second day on the market became the 4th top grossing app in the US App Store (Sports), number one in Norway, and was selling well around the world.

Feedback started coming in from customers, and they absolutely loved it. Many said it was the perfect product. We began collecting comments at:

http://racesplitter.com/testimonials

RaceBuilder — building on our momentum

We quickly shifted focus to RaceBuilder, a companion web-app to create, share and discovered races for import into RaceSplitter. This proved equally popular, and within two weeks more than 110 nordic ski races were published, containing 5,500 unique racers — including the World Championships in Oslo, Norway. More importantly, we established the beginnings of a central hub and community, on which we’ll be able to build and market services in the future.

The RaceBuilder website

Creating a race in RaceBuilder

Great products are discovered, not specified

One of the most important things revealed through the process of building RaceSplitter is that we could have never specified at the beginning of the project precisely how the final product would look and behave. (This observation has important implications for the client-services business!) The “functional requirements” were satisfied during the first one-third of the effort ultimately spent. The final two-thirds were spent in iterations — transforming a functionally-complete product, into a great product.

As proposed in Getting Real, the user interface design led the process, and ultimately went through four revisions, with two of those resulting in the elimination of an entire level of interface hierarchy. Here’s a sequence of revisions in a couple of areas:

The active race screen

The active race screen shows the current race standings, as well as provides access to the timing function. In the original wireframes, we separated lap standings on individual screens, navigated through swiping. We also had the “stop race” button in the lower right corner. To access the timing interface, we used the “Record” terminology.

In subsequent revisions, leading to the final, we decided to display all laps on a single (scrollable) screen, and moved the “Stop” button to the bottom left, where it was less likely to be inadvertently tapped by the thumb of a right-handed user. We also used more explicit “Time Racers” terminology to access the timing interface.

The timing interface

The timing interface, from a UI perspective, was challenging. We created a live wireframe prototype of our initial idea for the interface, in which the racer’s bib identification and timing button are integrated into the same UI control.

Later, however, we realized that this interface would only allow for timing one racer at a time. In nordic races, groups of racers often pass together, and need to have the same split time applied to everyone in the group.

Taking inspiration from Apple’s Mail app on the iPhone, we created a “timing bar” interface, where multiple bib numbers can be added, and timed at once.

The timing interface can be seen in action in this video screencast.

We spent a lot of effort focusing on the details of the UI. For example, we created aesthetically pleasing blank slate screens, and we created a custom, efficient UI control for numerical fields whose modification tends to happen incrementally — such as the assignment of lap number to a timing entry.

Features — wolves in sheep’s clothing

We’ve always been aware of the importance of focusing on a product’s essential functions, and taking great care when adding features. This was probably one of the strongest messages from Getting Real — learning to say no to features.

That said, we still couldn’t help but add some nonessential, and seemingly innocent, features during development. Some of those features later turned out to be surprisingly complicated, and costly.

For example, we added the ability to record a timing entry for a racer that wasn’t in the start list. Later, we realized we’d also need to design the UI to assign that blank entry to a racer. In designing that UI, it occurred to us that we’d also need to offer the ability to create a completely new racer (not existing in the database of racers), and then when creating a new racer, offer the possibility to create a new team. It didn’t stop there. We then had to make sure the app behaved sensibly in other areas, such as exporting of data, if the user chose not to assign that blank entry to anybody.

And on it went. We learned the hard way the unintended consequences of seemingly simple features.

A different view of “minimum viable product”

As users of several 1.0 products ourselves, we’ve gotten the impression that for many, the concept of “minimum viable products” extends beyond the essential features, to the entire user experience. We believe that although a 1.0 may be slim on features, its UI and overall user experience should be polished, and as frictionless as possible.

In RaceSplitter, after 200 hours, we had a working app. But then we spent another 450 hours perfecting the execution of that core application. The UI went through four revisions, focusing on the smallest details.

The results speak for themselves. Customers of RaceSplitter, rather than saying, “Good idea, let’s see where this is in six months.” (and then never come back, nor tell anyone about the product), are shouting praise from the rooftops. Not a day goes by that we don’t receive an email from somebody saying, “This app is perfect!”

Of course, we get a lot of feature requests, and it’s a bit of irony that many of those requests would work against the simplicity and frictionless interface that the customers value so much. Perhaps that’s why the designers of successful products are sometimes unpopular and under-appreciated; they’re the ones always saying, “No.”

Don’t be afraid to price an app beyond $0.99

To determine our pricing we surveyed coaches, who said they’d pay $50 for such an app. Then we spoke to some parents to understand what would be the impulse buy threshold, and we came to believe that was around $25. We settled on $24.99, hoping the app would then be popular among coaches, parents and enthusiasts.

We will experiment with pricing in the future, but so far we’ve not had any complaints about the product’s price. We’ve been told by several customers that although they initially tried the cheaper alternatives, they ultimately settled on our app, and feel it represents a good value to them.

Learning from the old advertising industry

There are generations of advertising industry history and experience available to us, from which we in the modern web/mobile world can benefit. Through a study of this industry, and particularly David Ogilvy, we gained insights on the things that deserve focus, and learned several effective techniques.

For example, we learned about the related influence and importance of headlines, subheads, image captions, and, above all, good copy. As emphasized in Getting Real, it’s all part of “design.”

We also learned that measuring performance is what matters, as the data often contradicts your intuition. We did a lot of A/B testing on our website, and found that by just adjusting the headline, we could double our conversions. As opposed to headlines about “ease of use” and “affordability,” we found that a headline that quickly established who the product is for (“coaches, parents & enthusiasts”), was the clear winner. (The worst was a title which labeled the product as a “professional” tool.)

Spreading the word

Our marketing of the application focused on three things:

Online ads
Direct email
Promote word-of-mouth

Online ads — the winner is Google

For online ads, we ran both Google and Facebook ad campaigns (multiple ads in each network), as well as a direct banner ad campaign at a site where coaches hang out. After a month, we calculated our cost per conversion (where conversion is clicking the buy button, leading to iTunes). The costs were unacceptably high for the dedicated banner ad, as well as Facebook, but acceptable at Google.

Given how Facebook allows you to precisely target your audience (age, interests, geography, etc.) we were a little surprised how poorly the ads did there. But when you step back and think that people go to Facebook to socialize, and to Google to look for stuff, the results start to make sense.

Direct email

Through a couple of month’s research, we compiled a list of coaches and associations in a variety of sports. We needed to directly email these people, and to avoid coming across as spammers, we crafted the emails such that we both informed the reader of the product, as well as solicited feedback from them in terms of the application’s current applicability to their sport. We asked in which areas it might need to be modified or enhanced to more specifically address their needs. So that they could experience the app without having to purchase it, we created a couple of video screencasts of the application in action.

This approach worked really well. There was a clear correlation of sales to emails sent, and at the same time, we received an absolute wealth of expert domain insight, and developed some healthy relationships with key people in a variety of sports.

Promote word-of-mouth

This was the easiest part, and involved three important lessons from REWORK.

First, everything is marketing.

From the app, to the website, to our customer support emails, we want every aspect of interfacing with RaceSplitter to result in our customers thinking, “I’ve got to tell people about this!”

Second, nobody likes plastic flowers.

We decided to produce our own screencasts for the site, in order to quickly have some instructional videos available. When we later thought about commissioning a professional voice-over artist to make them sound better, we were surprised to discover how well our customers responded to hearing the voice of the person who was also responding to their support emails. Despite the imperfections and obviously non-professional voice, the reinforcement of the personal relationship seems valuable.

Finally, speed changes everything.

So far, we’ve been able to respond to support enquiries typically within a couple of hours; and often immediately. Customers absolutely love that, and seem to directly equate that to “caring.”

Niche market, beyond the design & development industry

As we’ve watched others transition from providing client services to becoming product companies, we’ve seen a tendency to create products targeted to the design & development communities.

One aspect of RaceSplitter that appealed to us was the fact that it’s a niche market, under-represented by companies with deep design & development capabilities, but one in which, on a global scale, presents a good business opportunity. We believe there’s a tremendous number of similar niches out there, and that design companies looking to make the jump to products should seek them out, as they represent markets full of people just waiting for a usable solution to their needs to come along.

Product creation is uniquely satisfying

Before I got into Brazilian Jiu-Jitsu, I used to work out regularly at the gym. The motivation for going was, “I need to go, because I need to get the exercise.” Later, after getting hooked on BJJ, I didn’t go for the exercise; I went out of passion. And a positive consequence is that in training BJJ, I’m able to push myself far more than I ever could in the gym, and gain a much higher level of fitness.

Something similar happened in the development of RaceSplitter. We become more deeply engaged than any project we’ve been involved with in the past. There wasn’t any question of finding motivation; on the contrary, it took discipline to stop working in the evenings. That is how we want to spend out time!

Concluding thoughts

The experience of designing, developing and selling RaceSplitter has, for us, been priceless. We’ve gained the confidence that we have the ability to succeed as a product company. We’ve experienced the joy of hearing from customers thrilled in using a product we’ve created. We’ve learned things that simply weren’t possible being on the service-provider side of the table. We’ve created a product that is already successful, and has lots of potential for growth. And, in the process, we’ve had more fun and become more engaged than we have since our company’s beginning.

The experience also served, for us, as a real-world validation of the ideas in Getting Real and REWORK. In a world of both increasing complexity and human interaction with software, success is going to be found in the perfect execution of simple, focused products, delivered by companies that find a way to connect personally with their customers. That’s easier said than done. The processes of the past simply don’t get us there, and these books propose an alternative.

On the pricing of services work

2010-11-18T00:00:00+00:00

When I started Makalu, over a decade ago, I remember longing for a user’s manual to help with questions like, “How much should I charge?” and “How should I price my work?” This article describes how we approached these questions, and includes discussion of the recent controversy over the pricing of the 37signals’s (@37signals) blog redesign project.

Determination of a minimum hourly rate

Regardless of how you plan to charge for your work—i.e. on a project basis (fixed-fee), or an hourly basis—you still need to figure out the minimum amount you need to be earning per charged hour.

Available hours. We began by computing the number of hours per year each of our staff will work, on average, taking into account public holidays (12 days, in Germany), vacation (30 days, in Germany) and weekends (104 days, on Earth). So in Germany, that’s 219 working days per year, or 1,752 available working hours.

Chargeable hours. It’s important to recognize that not all of a person’s available time will end up being chargeable. People will sometimes be supporting bids, sometimes working on overestimated projects, sometimes idle, sometimes off sick, etc. In our case, we assumed a chargeability figure of about 70% (which turns out to be pretty consistent with the service industry as a whole). With that, we’re down to about 1,226 chargeable hours per year, per person.

Minimal hourly rate. To compute a minimum hourly rate, we need to divide the minimum revenue we need to make per person, by those 1,226 chargeable hours. The total minimum revenue equals our employment costs (salary, benefits, social security, etc.), all overhead expenses (office rent, support staff, marketing, accounting, legal, etc.), plus the minimum profit we want to make.

Example. In a hypothetical scenario in which a company’s staff costs, on average, $75,000 per year per person, with overheads equivalent to say 20% of employment costs, and wanting to make a 15% profit, the minimum hourly rate would be roughly $85/hour. (That wasn’t the particular number in Makalu’s case ten years ago, but might seem a reasonable starting point today.)

Making adjustments according to supply and demand.

Over time, as we produced good work (and through some lucky breaks), we found ourselves with consistently more demands on our time than we had availability (and we note, however, that doesn’t necessarily imply a higher level of chargeability per person.)

As is natural in free markets, prices adjust in order to balance supply and demand, and so we began to slowly increase our hourly rate, in order to alleviate the excess demand. (Some companies would have just ramped up their staff count. In Makalu, however, we place far greater importance on maintaining our ability to produce great work, and that means only hiring great people. We simply couldn’t find legions of great people; we’ve been lucky to find one per year!)

An interesting (though obvious, after-the-fact) consequence of increasing our hourly rate, is that the customers that were left tended to be exactly the type of customers we’ve always wanted to work for — they appreciate, value and demand high quality, and are doing interesting things!

Of course, I sometimes wonder whether we should have started out with higher rates to begin with. In hindsight, though, I don’t regret starting with lower rates, because at least I know that the price we do charge is based on something non-arbitrary. I know how we got here, and that knowledge frequently proves useful.

But what about the others?

Occasionally, I hear stories of companies working in our domain charging astronomical rates (considerably higher than what we charge), and told in a way to suggest that such rates are a sort of “industry standard,” which all serious firms are charging. My instinctive reaction is usually, “Gosh, we must be really underselling ourselves. Have I completely missed the mark?”

But then I remember that it’s human nature to sometimes overstate the truth. There may well be companies out there charging that much (due to their own demand), but I’ve got a couple pieces of evidence against the notion that we’ve somehow missed the boat.

I’ve once seen an invoice from one of our high-profile competitors, and the charged average hourly rate was actually lower than ours.
One of our best customers (and an industry icon) generally tells us their project budgets up front. When I divide their budgets by how long I believe it’ll take us to do the work, I almost always end up with an hourly rate very close to what we charge.

Once again, I think it can be wise to sometimes just ignore what you hear about others, and have confidence in your own experience and objectivity.

Hourly or project? Effort or value?

How should you charge for your work, on an hourly or project (fixed-fee) basis? And if you charge by project, should it be based on effort estimate, or based on the value you believe your work has to your client. These seem to be eternally debated questions, and I don’t have answers that would likely apply to everyone.

Although we occasionally take on the rare fixed-fee project, here at Makalu, we almost always insist on charging for our work by the hour.

Fixed-fee projects tend to put the client and provider on opposite sides of the table, with orthogonal motivations. The client’s motivation is to achieve as much as possible within the fixed price, while the provider’s motivation is to complete the project as quickly as possible, maximizing profit and minimizing risks (and as a possible consequence, minimizing innovation).

Fixed-fee projects also tend to demand that detailed requirements are agreed up front, the production of which often waste time and money, as final products rarely reflect original specifications. And such projects also suffer in the close monitoring of requirements, and the production, negotiation and agreement of contract modifications when the inevitable scope changes occur as the project evolves.

Charging hourly, on the other hand, works to align the client and provider interests, and allows for the agile, iterative approach to project development that’s becoming ever more accepted as the best path to efficiently meeting objectives, while maintaining a balance of value and cost.

When Makalu gets a project request, twelve years of experience allows me to make a reasonable rough estimate of the required effort, which I can multiply by our standard hourly rate to immediately provide the customer with a ballpark estimate. It won’t be perfect, but at least we can quickly establish whether the project is financially feasible.

If it is, and based on that rough estimate, we’ll begin working on an hourly basis (invoicing our time periodically; say monthly). This allows us to manage cost and scope, together with the customer, and generally has resulted (for us) in the development of successful products, with little of the friction typically found in fixed-price engagements. And that makes us happy!

For some potential customers, a natural reaction is, “We won’t go into a project if we don’t know precisely what we’re going to get for our money.” Such a reaction is understandable, but, unfortunately, there’s an enormous history of failed projects in our industry supporting the notion that fixed-price usually isn’t the best way to go.

For others (particularly in countries like Spain), their reaction is, “We’d never enter an open-ended hourly project, since you could cheat us by charging time you didn’t really spend.” Those are precisely the kind of customers Makalu doesn’t want to work with. Nothing good can come from working with a company that doesn’t have the foresight to see that cheating isn’t a sustainable strategy for a company like Makalu.

We want to have successful projects, and don’t want to spend our time in the wasteful paper-pushing and unproductive arguments that too often characterize fixed-price engagements. For those reasons, we took the decision to (generally) avoid customers who require fixed-priced engagements. Since taking that decision, our projects have gone absolutely great, and, just as importantly, the customers who we since work with have tended to be dream customers who share our passion for quality.

But what about value pricing?

We recently bid on the redesign of the 37signals blog, “Signal vs Noise,” and in the process entered an interesting twitter exchange with Oliver Reichenstein (@iA) of Information Architects. His argument seemed to be (and there’s room for misinterpretation in exchanges of 140 characters) that the 37signals budget of $8,500 was far too cheap, compared to the value of a well-designed blog (to that particular company), and that their offer was disrespectful of the creative industry.

This would have been one of the rare fixed-priced projects in which Makalu would have been happy to participate. First, $8.5k would have almost certainly covered the amount of time we’d need to do the work. Secondly, we’ve been reading 37signals’s blog for years, and know they are reasonable people. If we were doing good work, and the scope increased or they wanted a particularly large number of iterations, we’re confident they would have worked with us. Finally, that project is going to bring whoever does it a lot of visibility, and (perhaps even more importantly) they will have the opportunity to develop a relationship with Jason, David and the other influential people at 37signals. There’s a lot of value in that.

But on the other hand, Oliver does make a valid point. In the “Build an Audience” chapter of 37signals’s new REWORK book, they imply a value of “hundreds of thousands, or millions” of dollar in having built an audience of close to 100,000 readers of their blog. So it’s easily arguable that a great redesign of such a blog has a value to 37signals far in excess of $8,500.

Even if I still don’t fully agree with his conclusions, Oliver’s arguments at least caused me to spend some time rethink pricing (and that’s a good thing to do from time to time). Should design be priced differently than development, for instance? I supposed if all I did was design logos, charging hourly wouldn’t be a smart strategy. But what about a business in which the work usually spans the whole spectrum from strategy to tactics, design to development, and even operations?

Although I continue to keep an open mind on the subject, for now, I’ll stick with our tried-and-true hourly and effort-based pricing. It may occasionally result in (subjectively) unbalanced value to our customers, but I can live that. It’s a model that seems equitable, and has proven to work for Makalu, allowing us to create great products, for amazing customers, remain profitable, and be happy in the process.

And, as my colleague Alex pointed out, it also happens to be the model of a firm we tremendously admire, IDEO, which (at least on this point) puts us in good company.

Why we do not sign NDAs at Makalu

2010-09-29T00:00:00+00:00

Recently, a potential new customer expressed surprise when I told him that we at Makalu usually don’t sign NDAs. Mentioning that he’d found plenty of other companies willing to sign his NDA, I restated commitment to our position, and acceptance that we’d unfortunately have to miss the opportunity. There are others who don’t sign NDAs, and their reasons range from the philosophical, to the financial, to the practical:

It feels like an expression of distrust (though, I’m not fully behind that one; life has taught me that trust is something earned, not something granted by default).
It implies an immediate cost, as no serious company is going to sign an NDA without having a lawyer read through it.
For companies — particularly VCs and services firms — that meet frequently with potential customers wanting to discuss ideas, there’s just too much risk of idea-overlap and inadvertently entering into a situation of legal liability.
Exploiting ideas and information simply wouldn’t form part of a sustainable business strategy, because as soon as that happened, the whole world would know via Google, and the company’s reputation would go straight down the drain.

While these are all valid reasons for not signing an NDA, for us at Makalu, there’s actually something far more important — that is, demanding signature of an NDA isn’t usually a characteristic of the right kind of client for us.

You see, we want to spend as much of our time as possible, working towards the creation of great products. That’s our objective. Working with the right type of client is essential to that objective, and those clients tend to share some common characteristics.

In our experience, the right type of client will tend to share our belief that ideas are cheap, and that successful execution is what’s truly important, rare and valuable. They generally won’t even ask for an NDA to be signed. If something’s confidential, they’ll just say, “Hey, keep this under wraps for now.”
In a similar vein, the right kind of customer will share our beliefs about the process which leads to great products, and the ideal engagement model that derives from that process.

About four years ago, we decided to no longer compromise on our beliefs, and the results have been nothing short of amazing. We’ve been thrilled to discover that some of the companies we’ve most admired happen to share our views, and have even become our clients because of our beliefs. Time after time, we’ve confirmed that engaging those clients that share our beliefs is a general precursor to successful, enjoyable projects. And in the process, we’ve created some great products, delivered some major success and value, and have had a blast doing it.

I’m not suggesting that the Makalu way is the “right way” for everybody. And I’m not saying there’s necessarily anything wrong with companies that ask for NDAs. In fact, I’m not a fan of absolutes in any regard.

What I do believe though, is that decisions and policies consistently guided by a set of values, is likely to be the best strategy for anyone. Makalu’s decisions are no longer guided by potential for profit, or need of work, but rather by those conditions necessary for us to create great products, and that, for us, has made all the difference.