Shipping unlocks a feedback loop that confirms or challenges those assumptions. It makes new things possible for your customers, and gives you the opportunity to focus on the next thing.

Shipping brings life to your team, to your product, and to your customers. Shipping is your company’s heartbeat.

Shipping will try to kill you

The scramble to get that one last feature done, the late nights, the compromises, the sinking feeling when we realise something major is broken, the post-mortems… It’s agony, but if it was easy everyone would do it. Shipping exposes mistakes. We’re nervous about it, and our natural reaction is to do it reluctantly and infrequently, which actually carries higher risk, causing more reluctance in the future.

The cost of shipping is approaching zero

Not too long ago, shipping software involved actual ships, disks, and printed manuals. It happened perhaps once a year. Bug fixes weren’t automatic over the internet like today. Everything was slower and more controlled. The cost of shipping was massive, the consequence of a mistake was large. Today, the cost of shipping has approached zero. Most people can deploy in seconds or minutes with a single command or button click. With a little thought you can do that without your customers noticing, and with automated monitoring you’ll find out immediately if something goes wrong.

Despite the cost of shipping approaching zero, many people still ship software guided by very old habits.

Shipping cadence defines your company

The cadence at which you ship defines your company. A yearly cadence results in a very structured approach to the design->build->test cycle. A few months of building, while the rest is spend fixing. Engineers can join and leave before seeing their hard work end up in the hands of customers. The approach to design becomes one of anticipating all possible needs, rather than focusing and iterating on the important ones.

Obstacles downstream propagate upstream

An obstacle downstream propagates upstream. If you’re not allowed to implement new ideas, you stop having them.
- Paul Graham

The right approach to shipping has a positive influence on your company’s productivity and your team’s happiness & job satisfaction. Shipping infrequently is an obstacle. Ship slow, and you’ll introduce challenges that push you to ship even slower. Ship frequently, and see positive effects everywhere in your company. For example, lets examine how behaviour changes along with shipping frequency, while handling a simple request from a customer.

Lets say a customer gets in touch to say “No matter what I do, I cannot save my name correctly, I think it doesn’t like hyphens“. In a company where you ship continuously, you see this and think Simple — I’ll tweak a test and a regex pattern, get a quick code review from my buddy beside me, merge to mainline, and 1 minute later when it’s deployed to production, reply to the customer: “Sorry about this, it’s fixed now, thanks for letting us know“. They’ll reply: “Wow, thanks for fixing so quickly“. High fives all around!

If we stretch the time to production (TTP) out a little, even to 10 minutes, the behaviour changes. You either do the same, but reply saying it’ll be fixed with our next deploy (probably 10 minutes) – or you wait, so that you can communicate with certainty. The waiting is time where you’ll shift focus to something else, but have the baggage of having to follow up. Perhaps you’ll think, I’ll have a quick coffee, then move on to something else afterwards. Even though your deployments are entirely automated, you lose time because of waiting and losing focus.

If TTP is hours, the behaviour changes again. No longer can you say with certainty when the change will be out there, so you’re tempted to batch up with other similar small changes. You postpone replying until you get time to do it, sometimes forgetting about it. You’re less likely to take prompt action, wow’ing the customer, and you pay some mental cost for having it on a todo list. Since getting to production takes hours now, your team will start restricting to morning only deploys, so miss that slot and it’s further delays.

If TTP is days, it exacerbates that further – perhaps you’ll reply “Thanks for letting us know. We’ll fix this in our next sprint”. It gets bundled in with a whole load of other small low, priority items, you spend more time debating estimates, and priorities, than the first guy took to fix it and reply to the customer. Miss the beginning of week deploy window and further slippage. The larger releases bring higher risk, you’ll tell your customer it’s fixed, only to later require rolling back because of a separate change. Your bug database gets bigger and bigger, with little details that you’ll probably never fix.

When TTP is weeks, it exaggerates that even further – perhaps you’ll reply “Sorry about this, I’ll let the development team know” or something equally lame from your customer’s standpoint. Deep down you realise nothing will be fixed, and the job of talking to customers becomes a cost or hassle, rather than an opportunity to improve your product and nurture happy loyal customers.

Shipping continuously

Better approaches to writing or testing software help us iterate more quickly and confidently, but the benefits are quite local to engineering teams. Continuous shipping on the other hand, touches all parts of your company, as do the benefits, and the behaviours it enables and encourages.

Linkedin’s transition to continuous deployment is linked to their recent financial success.

Good products, are a side effect of combining good people with an idea in an environment that helps those people to kick ass. Your attitude to shipping is a big part of that environment you create.

Shipping breathes life into how we think. The feedback loop helps us learn, gain confidence in making quick decisions, and build momentum. Momentum in product improvements excites and engages our customers. Seeing quickly the benefits of our hard work, motivates us to do more. Building a team where people can work hard and move fast attracts others to join you – hiring gets easier.

Shipping continuously isn’t an achievement you unlock and then move on. You’ve got to constantly obsess about it. If you believe in the benefits it brings, you’ll be driven to shrink 20 minutes down to 1 minute or less, you’ll consider ‘ability to ship‘ as an equal to ‘does it scale‘ when building new systems. And you’ll do that because of all the life it breathes into your company and your product.

Shipping is your company’s heartbeat.

As always, an MP3 recording of the conversation is available (40 minutes, 50MB), and there is an edited transcript below, with additional graphics to illustrate some ideas.

Des: Hi there, and welcome to Inside Intercom. Today’s guest is Garrett Dimon, the author of Starting + Sustaining, a practical guide for building and maintaining your own web businesses, and the founder of Sifter, a very popular issue tracker. Hi, Garrett.

Garrett: How’s it going?

Des: Great, thanks. I’d like to start this off by going back a bit. Five years ago you decided to quit your job, cut your salary to near nothing, move into a 500 square foot apartment, and start building Sifter, something you’d been sketching our for eight years previous. I want to know why.

Garrett: I have always had a fascination with issue tracking. When I got out of college, I went to work at Sapient and basically got thrown into very large projects that had to have a formal issue tracking process. So from the moment I was out of college, I was kind of tossed into that world and became very, very knowledgeable about bug and issue tracking.

And then after leaving—well getting laid off as the dot-com bubble burst—that experience stuck with me. And at my next couple of jobs the bug tracking was non-existent. At one point, I was working for a company who had outsourced development. I asked “Where do I report bugs?” And they emailed me a PDF and they said “Here, print this out and fax it to us.”

That was the point where I realised that not every company in the world has a great bug tracking process. I just kind of became curious and fascinated by that. I then spent pretty much my entire career doing consulting work for small to mid-size projects where the teams were never larger than 25 people. Big enough to need a formal process, but not big enough to need tools like FogBugz or JIRA. At the time, there wasn’t much else out there. You either took everything and used one of those apps, or took nothing.

Our clients wouldn’t use those apps. They’re not deeply technical people. They were intimidated by them. So we’d have a formal issue tracking process and it’d be all set up and we planned it out, and the clients would log in, and then within the next day, they would just email developers. And so that whole process basically fell apart simply because they wouldn’t use the tools we were using.

All of that experience over the years added up, and haunted me in the back of my head. I would always sketch and play around and explore. In hindsight it was inevitable that I would launch a bug tracker.

Des: Lots of what makes Sifter a great product is its fantastic design. You have some great screenshots of iterations online from showing hundreds of iterations over the header. Aside from the interface, how much of Sifter is about enforcing or suggesting a process to people?

Garrett: You know, I wouldn’t say it’s suggesting a process because it’s still fairly flexible. It’s very rigid in terms of options, but it’s flexible in terms of how the existing options can be used. There’s a karaoke bar in Portland that uses Sifter to manage tasks between bartenders and management. So the flexibility is there. Our goal is: let’s build something for the people who don’t need the complexity of the larger bug trackers. Build a tool so they don’t have to worry about configuration. By minimizing all that and putting constraints in place, it simplifies the burden on them to figure out how to use it and how to best apply it. It just makes it easy enough for them to hop in and start using it without feeling overwhelmed or turned off by all the options.

Des: One of the pieces of Sifter that is reasonably opinionated is that you don’t allow tickets to be on hold. Is that correct?

Garrett: Yeah, absolutely. That’s kind of the digital equivalent of sweeping it under the rug. You know, it sounds good. But once you start using it it’s just “I’m not going to take this issue seriously, so let’s just toss it over here and maybe that’ll we’ll come back to it later.” My view is fish or cut bait. If you’re not going to do anything about it, close the issue. If you’re going to do something about it later, you can reopen it.

If you get into too granular of a status, you end up with states that aren’t really states. They’re more kind of just various bits of information about the issue. A lot of times, people want specific resolutions. When an issue is resolved, they don’t want to put ‘resolved’, they want to put ‘won’t fix’ or ‘duplicate’ or whatever. And really, that’s not a state so much as a resolution. And resolutions are best captured in text where you explain why you made the decision you made so that for historical purposes you can circle back later and see. Saying ‘won’t fix’ as a state is a cop-out because it lets you not explain why you won’t fix it. And then a month later down the road, you come back and see ‘won’t fix’, but why did we decide we wouldn’t fix this?

Des: When I’ve used issue trackers that allow ambiguous states like ‘on hold’ tickets tend to pile up in whatever the most vague non-committed status is. In the end you can’t see the wood through the trees, because when you log in there’s like 800 issues, 5 of which are actually pressing, relevant issues, 795 of which are aspirational, “We’re going to do this someday”” type things.

Garrett: We do the same thing with milestones. The only way milestones are considered closed is once the due date is passed and all of the issues within it are closed. Often people are like “How do I close a milestone?” and I’m like, “Well, finish all of the work you put in there.”

If people could just close a milestone, they’d sweep all of that unfinished work under the rug. You have to make sure that you don’t just make it easy for things to just kind of accumulate without any kind of outcome.

Des: Have you ever tried any tactics to increase adoption of Sifter with teams? Do you remind people to come back and check it, or send out reports on how it’s been working for a team?

Garrett: I’m in the mind that if we’re not giving people something valuable in an email, that I don’t want to send people emails. I’m starting to get to the point where I can see we need to do more to educate people and help people use Sifter better before we start just making it more complicated.

On Traction, from 50 to 15,000

Des: Do you remember your first customer?

Garrett: I remember lots of first customers. It depends on if you count friends or not.

Des: The first customer you didn’t know.

Garrett: I don’t even know if I could say there was a first customer, because…

Des: You probably had 50 customers on the first day?

Garrett: Yeah. Like, the first day, we had a handful that signed up.

Des: And how did you get them?

Garrett: Really just through blogging, and, I guess the waiting list helped. I had an email list, and it was about 1,000 people and we sent out a, you know, hey, we’re live, email to those people. But most of it I think just came from blogging and from people who were interested in Sifter because by talking about it long before it was ready, it kind of pre-selected a certain audience that was at least vaguely interested in some of, you know, the thought process, and at least were fascinated by some of the same sick and twisted bug tracking stuff that I’m fascinated by. So I think that helped a lot.

Des: And where is it up to today? Do you have any numbers that are public around how many customers you have?

Garrett: Over any 30-day period, we have somewhere between 12,000 to 15,000 active users.

Des: How does that grow?

Garrett: Very, very linearly, and really through word of mouth. We’ve done a fair amount of advertising, but when it comes down to it, the best way we’ve grown really I feel is from things like Twitter and word of mouth. Just people signing up for it that have either used it at previous jobs or know people who have used it and recommended it, and it’s kind of just bit by bit expanded like that.

Des: So there hasn’t been any key growth activities. You didn’t go viral or anything?

Garrett: No, definitely not. In hindsight it was a mistake to make all of the accounts heavily sandboxed instead of trying to add an element of sharing to it. It’s turned out well, but I definitely think if I could go back I’d try to make it so that the accounts could interact more seamlessly and kind of enable that kind of growth.

Des: Today, you have thousands of active monthly customers. Do you get lots of requests, feedback, et cetera?

Garrett: Absolutely. The feature requests have never ended and, last time I checked, they’re still going. Probably something like 60% of our emails are related to feature requests.

Des: Do you think that’s a function of how simple you’ve kept the product?

Garrett: I think it’s a combination of things. It’s driven in part by the fact that I have kept Sifter so simple that there are a lot of features to be desired. The other part I think is the target audience, being that it’s developers and the sort, they’re the type who are definitely wired to think in terms of features and how to execute on ideas or how to improve things. So they naturally just have a lot of ideas bubbling up. And then finally, it’s probably just related to the fact that anytime anybody emails me, I reply to something like 91% of our emails in under an hour.

Des: That’s pretty impressive.

Garrett: That’s not just a yes/no reply. That’s always a pretty in-depth reply, almost starting a discussion about the feature. Every time I get an email, even if it’s something I thought about before, you know, even if it’s later that evening, I still set aside time and think through it and think “Is this still the right decision? Has anything changed?”

Des: Right. What’s the most frequent request that you know you’re probably never going to do?

Garrett: A month ago, I would have said text formatting. But I think there’s a chance we might put in some form of text formatting. I don’t know when or how.

Des: You mean like bold and italics, that sort of thing?

Garrett: Yeah, we’ve dabbled in it and we’ve explored it and it’s certainly probably one of the front-running requests. There are some consequences to it. Even the current Basecamp implementation, I was writing something in there on somebody else’s account and trying to use it, and I just tried to bold something, or unbold it, and all of a sudden everything got all wonky and I had to reload the page.

Des: It does seem like WYSISYG and others, those sort of things, they do seem like a serious iceberg in web applications. What the user see is tiny in comparison to the development effort.

Garrett: Exactly. It’s a very ugly, nasty problem. I don’t want to just toss it in just to make people happy, because ultimately they’ll end up more unhappy with a poor solution than they would with no solution at all.

Picking Price Points

Des: Let’s talk about pricing. In your book, you outlined a lot of different lessons you learned along the way. You’re currently at a situation where your smallest plan is $29. How did you get there? Did you start it cheaper?

Garrett: We originally started with a $14 plan as well. Over time we realized that the $14 plan really wasn’t pulling its weight. Especially as obsessive as I am about really providing good customer support and getting back to people and having in-depth conversations with people. The $14 plan just made it difficult to really hold up and deliver on our end of the bargain if we’re losing money on a certain swath of customers.

Des: Would your definition of losing money be that the support cost of these additional customers wasn’t justified by—

Garrett: Yeah, it was all driven by the support costs. The biggest cost to support isn’t necessarily the cost of answering them so much as the opportunity cost of every time I’m answering a support email, it’s taking me away from doing development work or otherwise improving the product. Our $14 plan produced the highest volume of support requests from the lowest lifetime value, so the corollary was basically we were spending a lot of opportunity cost on customers who probably weren’t going to use Sifter very long, so ultimately we were losing money on them.

Des: When you dropped the $14 plan, did that affect your sign-up and conversion rates?

Garrett: Yeah, definitely. Our original goal was simply thinking well, if we remove the $14 plan, if even half of those customers that would have signed up for the $14 plan still sign up for the $29 plan, then we’ll come out ahead—well, at least break even. So we make the same amount of revenue on half as many customers, at least in that class.

Des: And how did that work out?

Garrett: Our conversion rate from site visitor to trial plummeted. It decreased by 50%. So we had 50% fewer trials signing up. However, our total amount of $29 plans skyrocketed. Fewer people signed up but the ones who did were much more likely to sign up, and they were fine going ahead and signing up on the $29 plan. We were definitely were happy with how it worked out… lots of the customers who would have signed up for $14 went ahead and signed up for the $29 plan without skipping a beat.

Des: Did you ever consider a free plan?

Garrett: No. We have thought about bringing back a very cheap plan. Based on my experience, if you’re charging less than $10 in the business space, that might as well be free. Charging money is just there to make sure that people are at least a little bit engaged in the system. A lot of people use anything if it’s free, so by putting a little bit of a barrier there, you tend to kind of pre-qualify customers.

Des: You don’t charge per seat, which the other issue trackers do. Why not?

Garrett: My philosophy is that the most valuable feature of any kind of collaborative software, but in particular bug and issue tracking, is participation. That’s not really a feature that you can factor in like other features. It doesn’t matter how great the issue tracker is. If nobody uses it, then it’s not going to work.

Des: When you look at Sifter and think about it over the next five years, what big challenges do you see? Are you worried about someone else coming in and gobbling up the sort of simple market space, or do you think you’ll take the product upmarket and add some of these bigger features?

Garrett: We’ll add some features. The market is already so incredibly fragmented and it’s a market I don’t believe is ever going to be unified because there’s just too many different preferences, team sizes, technology stacks, development processes and workflows that it’s more like Goldilocks where, you know, this porridge is too hot, this porridge is too cold, this one’s just right. Every team is going to be so different.

If anything, we need to do a better job of simplifying our existing feature set. Not to say removing features, but making the existing stuff work 10 times better than it does. So we’re going to add some other stuff for sure. In particular, we’ve been spending a lot of time on our API so that Sifter becomes a better neighbour with all of the other tools, whereas right now it’s an iceberg all on its own.

Other than that, a lot of what I want us to do is to invest in resources and just helping people learn how to do an appropriate level of bug tracking given their team size or project size or whatever the factor is for them.

Des: That’s an education challenge for you, right? You need to effectively teach your customers how to best make use of their time bug tracking.

Garrett: Yeah. It’s not even going to be purely about showing you how to use Sifter. It’s going to be about bug tracking, and if Sifter’s right for you, awesome. If it’s not, then hopefully you at least know some more. I’d love to see us grow, but I don’t want to see us grow and get people who don’t like Sifter. I want to see us grow to people who like Sifter, and if Sifter is not right for people, I want to see them happy somewhere else rather than see us trying to make a few extra dollars.

Des: What sort of stuff are you considering for educational resources?

Garrett: We’ve always blogged. That ebbs and flows with how deep I am in development. The first thing we want to do is create content for reading, then potentially a week-long email course, where every day we send a blog post via email. Let people opt into those free courses.

Where to from here?

Des: Have you ever considered a second product?

Garrett: Definitely. We talk about it all the time. But we feel like there’s so much room left with Sifter. I was even afraid of writing a book. But adding a second product just creates a whole other layer of distraction, and I feel like for us to create another product like that is almost like saying, oh, we feel Sifter’s perfect and doesn’t need to improve.

Des: So, what motivated you to take time away from Sifter for the book?

Garrett: I’d been blogging about some ideas and had always gotten good feedback. People say things like “I’m in that exact same spot you were five years ago.” People just—they appreciated that stuff that I was sharing so I figured I could probably write a book and make this a lot easier on other people.

I figured if I could go back in time and tell myself everything that I know now, I would’ve probably shaved months of effort off my life and a lot of misery.

Des: What are the key lessons that you’d love to get into a time machine and tell yourself?

Garrett: At one point we encountered some fraud. Somebody was just validating stolen credit card numbers using the credit card form on Sifter, and out-of-pocket, it cost us maybe $200 in credit card fees. You know, really nothing in the grand scheme of things. But for two whole weeks, it just drove me nuts. In reality, all we needed to do was just stop it and move on. Another time lost about eight hours of customer data. We thought we had enough data redundancy. We had backups. You know, everybody’s always got backups. Our backups just weren’t robust enough. And we had never really thought about, oh, there’s just so many scenarios for losing data and things that can go wrong. And in this case, at the time we just didn’t have thorough enough stuff.

The Numbers Before the Business

Des: Included with the book is a detailed SaaS planning spreadsheet. Did you create that for this book?

Garrett: No. A version of it was used when deciding whether we would try to build Sifter. We just made up a bunch of numbers, threw it in a spreadsheet, and said “That looks good enough. Let’s try it.”

Des: And that’s what you did. It’s been really interesting to hear about the background, because Sifter is a well-known product but is so very far from being an overnight success. Five years of blood and sweat and hard work. I think you said there was an inflection point, possibly three or four years in, where you actually got back up to where your original salary was?

Garrett: I think just this year we finally gave me a raise and brought me back up to where I was. At the same time, I know just through conversations with other people that I’m still underpaid relative to what I could go make right now. That’s one of those things.

Des: Do you ever draw projections to see at what point will you be like well above where you need to be?

Garrett: You mean where I’d be compared to if I had just made a real salary this whole time? I haven’t. I think here and there I’ve thought about it for like 5 or 10 minutes. When things were tough, I’d really be tempted. “Why do I not have a regular job with health insurance and benefits?” You know, wow, that sounds so attractive. Ultimately I always realise that I’d rather do what I’m doing now than make more money, without a doubt.

Des: Yeah. I think it’s good you feel that way for the sake of Sifter’s users, as well.

Garrett: Oh, yeah, absolutely. Well, now it’s definitely getting on track to where hopefully someday in the next five years, the money won’t even be a factor at all. But even if it was a factor, it doesn’t bother me. I’ve never enjoyed working on something this much. You know, I’ve never had so much stress and worked so hard, but at the same time, I’ve never felt more fulfilled or more sure of the fact that what I’m doing is what I should be doing.

Des: That’s great to hear. Thank you so much for your time, Garrett. It’s been great having you, and I’ll be sure to link up your book and your product, as well, in the show notes. Thanks so much for your time.

Garrett: Great. Thanks for having me.

More from Garrett

Garrett is on Twitter, and keeps both a personal blog and a product blog, and even finds time to post great presentations on Speakerdeck.

There are 2 types of disruption

Often CEOs declare their product to be disruptive, but fail to define in what manner. There are two types of disruption, and each one has a different measure of success. It is possible for a product to be disruptive in both styles but, if that is the plan, then progress must be measured accordingly.

New Market Disruption occurs when a product addresses non-consumption in an existing category, i.e. it is available for customers in a way the incumbents aren’t.

It could be cheaper, available in more places, in more countries, in more languages, etc. For some reason there are customers who can’t use the existing products, but they will be able to use this new one.

You can only claim your company is disruptive through new markets when the majority of your customers are unable to use any of the incumbents in the market.

Ryanair, the low cost airline, created an entire new market of budget travellers, not by stealing customers from Lufthansa or KLM, but by offering routes no one else did at prices that competed with trains and bus routes.

Low End Disruption is when a product steals the cheapest and worst customers from the bottom of an existing market, usually by figuring out a business model that works with a lower-cost offering. This opportunity presents itself when the leaders of the market are producing products far above what the market wants or needs. It’s also important to note that cost refers to “cost of use”, which is not necessarily financial. For example, it’s cheaper to tweet than it is to blog.

The product is clearly lower quality but the switching customers don’t notice or care as they are over-served by the existing products.

You can only claim your company is low end disruptive when you have a working and profitable business model that is stealing low value customers from incumbents.

An example of this is the Flip digital camera which stole customers from the digital camera companies by being more affordable and easy to use. Bought for $590,000,000 by Cisco, Flip was the darling of the camera industry, the poster child of low-end disruption. What could go wrong, right?

It turned out there was an even worse video camera at an even lower price point that the public were happy to use: the free camera found in iPhones and Android phones. 2 years after its acquisition Flip got to experience low end disruption itself. It was shut down, and 550 employees were made redundant.

This happens quicker than you’d think, which brings us to the next point.

Disruption can be swift

The seminal examples of disruption are things like Intel processors, steel mills and mainframe computers. This creates the impression that disruption takes years, even decades to fully impact an industry.

But that is not the case. In a world of online retail, app stores, and instant global availability market adoption takes minutes, not months. Whenever you see a claim of “fastest selling X in history” always remember that adoption is very quick these days and it’s accelerating. For example, Windows 3.1 sold 1 million copies in 2 months. Windows 8.0 sold 40 million copies in less than half the time.

Flip, as explained above, spent a mere 18 months at the top of the market before capitulating. Another example of is that of the satellite navigation companies Garmin and TomTom. In September 2007 they were worth a combined 38 billion dollars. A mere 12 months later, they weren’t even worth 8. What happened? The iPhone.

A 38 billion dollar industry loses 3/4 of its market cap in a year because someone decide to add a maps app to the home screen. Like I said, this happens quicker than you’d think.

If you’re claiming your product is disruptive and there aren’t barriers to adoption (e.g. technological/infrastructural barriers, existing long term contracts, language barriers, price barriers etc), then you should be expecting a massive adoption rate at a high speed. If you’re seeing slow adoption over time you can still have a successful billion dollar business, but it’s probably not a disruptive one.

Low Price Alone is not Disruptive

Disruptive innovations stem from technological or business model advantages that can scale as the business move upmarket in search of more-demanding customers.

Often you’ll see a new business appear offering for pennies what others charge thousands for. The above example highlights this. While a roadside motel offers the same product as the Four Seasons, it will not disrupt it, because to attract the customers who visit the Four Seasons it will need better locations, better gardens, better staff, and better facilities. In short, it will need to adopt the identical cost structure of the Four Seasons, meaning it could no longer out-price them.

The web version of this can be seen every few months when a new stock photography site appears, selling imagery for $1 per picture and claiming it’s disrupting GettyImages. Again, to move upmarket and appeal to magazines and high end design houses, they need to start hiring more talented photographers and offering a wider range of imagery. Doing this would see them adopt the Getty Images cost structure, and therefore not disrupting them.

There is, however, an opportunity for new market disruption here, in that plenty of the market will pay for 600px images to use in blogs and newsletters, are less quality sensitive, and cannot justify high costs per article or newsletter.

A Business Doesn’t Need to Disrupt

Not all successful businesses are disruptive ones. It’s entirely possible to just go toe to toe with an existing business and beat them at their own game. This can happen in lots of ways: better technology, design, product, route to market, price, etc. This is described in the graph above as “sustaining technology”, and is a well proven way to take.

If you are claiming your product is disruptive, keep note of 3 things. You have to decide what way it’s disruptive (so you can measure success), you don’t necessarily get a long time span to do your disruption, and if being cheap is your only angle you’re not disruptive.

This isn’t as easy as blindly screaming disruption every time someone launches “Spotify for Dentists”, but it’s worth considering nonetheless.

You can grab an MP3 of the file here, or there’s a full transcript below including imagery we created to visualise some of the concepts being discussed.

Des: Josh, could you introduce yourself to our readers and listeners?

Joshua: Sure. I’m a product and interface designer. I work at a company in Boston called HubSpot that acquired a company that I co-founded called Performable where we make software for professional marketers. I’ve been involved in design and the web for a long time; I’ve written a blog called Bokardo for 13 years. That’s how most people know me, they’ve read something that I’ve written there.

Wireframes are dead

Des: We’ve a few different topics we’d like to talk about. Maybe let’s just open up with a controversial one. Only about two weeks ago, you tweeted that “In case you didn’t get the memo, wireframing is dead and prototypes are the only way forward.” Obviously Twitter forces you to be concise, but even so, that’s pretty piercing. Can you expand on what your thinking is there?

Joshua: I want to be even more controversial. That statement is like 2 or 3 years late! Often I’ll just like throw out a statement on Twitter, to get first-blush kind of responses. So, there’s a little bit of that in there, but to get more specific, wireframes which are medium fidelity, grayscale, outline representations of an interface. I just don’t see the need for them in any real design workflow anymore.

The reason is twofold. One is that I think you can capture almost everything you need to capture in a pretty detailed sketch. Not a high fidelity sketch by any means. Not the ones where you use five different kinds of markers and you shade everything or whatever. The purpose of sketching is to communicate the major ideas, like, “What’s going to be on the page? What are the objects on the page? What are the things you can do to those objects?” Right? So, what are the nouns and verbs? And you can do that pretty darn well with a sketch, you know, white-boarding.

So I think that most of the things that people use wireframes for, in terms of visually laying stuff out and communicating pieces, can actually be done in sketches.

On the other hand if you want to actually test something, you need a prototype that someone can test. So, I would actually say that the role of the product designer is working with stakeholders to come up with those sketches, and then going right from that sketch all the way through to prototyping. That usually means high fidelity mockups that can be clickable or lightweight HTML prototypes that are clickable and usable. That’s really how I see workflows going forward. Almost every person that I talk to, who I think is doing decent design work, is doing it that way. I think wireframes are mostly a communication tool that is unnecessary, except in “big work” really.

Des: If I was to flesh out what you were saying there, it seems that if you want to try different ideas for layouts, use a sketch, but if you’re testing interactions you need a prototype. Is it possible that the only remaining advantage of a wireframe is that it’s an acceptable, shareable form of a sketch in a professional relationship?

Joshua: Yes. I would say that that’s probably what they’re mostly used for, and in a lot of people’s work that’s perfectly acceptable. I personally would not pay for wireframes, as a deliverable—but, you know, I did consulting for many years. I made wireframes over and over again, as deliverables, and I handed them off and they were passed around and they came back with feedback and all that. I think there’s definitely a need for them in some workflows. But I would fight extremely hard to remove them from any new project that I am involved with. There are other ways to solve the problems that wireframes solved. You just pass around sketches. We create digital representations of sketches all the time at work. Just shoot them with your iPhone. We take pictures of whiteboards, like every day.

A colleague of mine, Dan Ritzenthaler wrote up a nice blog post about this. In it he made a really great point: if you need to create wireframes so that other people can talk, you’re not talking to the right people. You’re probably not talking to the right stakeholders and that’s actually a problem that you need to solve. You need to have direct contact with the stakeholders.

Des: You’ve hit the crux of where the perceived value is and why it could and probably should be replaced. I often feel that the most exciting stuff happens before and after the wireframe in that the wireframe is just like the shareable artefact of a really, really valuable design session and, ultimately, ends up in the bin, once it gets taken any further whatsoever.

Joshua: It’s very similar to the results of usability testing. When I worked at User Interface Engineering with Jared Spool and the gang there we were paid very good money to write these enormous reports, but the thing was, that’s just actually for posterity’s sake. The real job is communicating the results immediately to the design team. If we’re not doing that, then no report is ever going to create empathy. I heard wireframes and some other things called “bill-liverables” the other day. Deliverables that you bill for.

Des: So, tell me this then. In HubSpot I assume you guys don’t rock around with hundreds of wireframes or 300 page PDFs getting passed around the hierarchy. How does your design process work? Are there any deliverables along the way?

Joshua: Am I walking the walk? Totally fair question. Outside of sketches and workable prototypes we have no deliverables. We work with like seven or eight product teams, and each one of those product teams has a product manager. Our best work is done when a designer and product manager essentially are on the same page every day. The way that I’m kind of thinking about it these days is: People who sketch together, get along.

People who sketch together and do that ideation phase of sketching where you take these concepts in your head and you draw them together. That is this really powerful moment, because you can’t lie and you can’t deceive in sketching.

If two people are talking for a week or something, about a new product, they actually might have very different conceptions about that product, even though their language was kind of the same. But once you get down to that level of sketching together, then there’s very little deception that can occur. So, that’s my mantra lately. People who sketch together get along.

Remote Working for Design Teams

Des: That makes sense to me. Here’s a question: Where does this fit in terms of remote working? Can you sketch remotely?

Joshua: Geez. Can you sketch remotely? That’s a great question. I haven’t really tried it. Yes. I haven’t tried it. I would say that it’s possible but it probably won’t be as efficient. You know?

Des: That would be my guess. I think you can throw back and forth photos, but the bandwidth and timeliness is reduced.

Joshua: That’s actually an important difference that you made, Des, that when you have to send something back and forth, it becomes a synchronous, linear process. “I’m waiting for you. Now you’re waiting for me.”

Des: Yes. It’s like you’re passing a ball back and forth, rather than like playing side by side.

Synchronous and Asynchronous Design

Joshua: It’s a different interaction than if you’re doing it at the same time. This is relevant because of the Yahoo brouhaha where Marissa Meyer said no-one could work remotely. Technology is getting to the point where it will feel like you’re in the same room with someone, and you’ll have like super big LCDs where you can see in good fidelity the sketching someone else is doing on a panel, 1,000 miles away. That will definitely come. I think doing it at the same time is actually the most beneficial part and it’s more important than the fidelity of anything you can pass back and forth.

Des: Yes, but no software is going to solve the timezone problem. You’re in Boston. It’s 9am for you, it’s 3pm here in Dublin. Your day is starting, mine is ending. In the early days of problem-solving, you really need like everyone working together, in the same time, sort of preferably in the same sort of humour at the same time of the day.

Joshua: Even with our design team, when we share something, be it on HipChat, LayerVault, or Invision, the feedback is never that great. It tends to be like “Yes, okay, I see that” but they just weren’t in the moment. People can talk way faster than they can communicate electronically, and all of those extra variables that human interaction give us, like tone of voice, inflection and body posture, language and all that, you cannot discount any of that.

The thing with Yahoo! People are looking at it like: “Oh. Yahoo is saying remote is bad and, therefore, they’re condemning that practice for everyone.” I wouldn’t look at it like that. Being part of companies who would try to create cultures has actually taught me a lot about the value of culture and the difficulty of doing it right.

Yahoo is making this decision for their company at this moment in time. They’ve accrued a tremendous number of bad habits over the last decade. Everyone knows the company is in trouble. This is just one of the ways that they are making a hard stance and saying, “You know what? Our culture is going to be a culture of working together in the same space. That’s it.”

I don’t think it’s a general statement on working remotely. I think you can still work remotely and be fine and it depends on the individual. It depends on their lifestyle. It depends on a whole bunch of things. For Yahoo, I actually think it’s a good choice that Marissa made, to do this. In fact, I think it’s the right choice in their case, because they need a huge direction change.

Des: I think the magnitude of changes they need are never going to be comfortable changes. You can’t turn a company around as much as Yahoo! needs to be turned around, while keeping, not just all the Yahoo employees, but all of the onlooking tech bloggers happy.

Are you testing interface, or ideas?

Des: Let’s bring it back a bit. What about testing in Hubspot? Do you guys do much new testing in that regard? Do you test sketches or prototypes?

Joshua: Yes. We rarely test sketches. However, the vast majority of usability testing we do is actually remote usability testing on clickable mockups and working prototypes.

Des: When you say “working prototypes” do you mean HTML, CSS stuff, JavaScript?

Joshua: Yes. We’ll do clickable mockups, or coded prototypes. I have found, though, there is this difference between types of problems that you’re trying to solve. I have seen people test prototypes that were bad ideas to begin with, so we’ve wasted time there. We wasted time building out a bad idea. Nowadays the first thing that we try to figure out is “Are we testing the concept, or the interface?”

Usability testing works best when you know the idea is good and you’re just testing to see if this interface allows that idea to happen.

So, we’re doing a lot more testing early at the sketch phase. We’re doing super-fast interviews with people. Here’s an example: we had this marketplace where you could buy services. Redesign a website, help you do your marketing, write blog posts for you, that kind of thing. We were pushing hard in that space asking “What kinds of services can we offer?” People are always obsessing over subject lines of the emails, so we wondered would people pay for a service where someone writes subject lines for them.

So, we did these mockups and we spent time designing it out. We got people in and they said “I would never use this.” It was such a quick thing. So, what we realised is that we needed this earlier check to see like, “Is this the right type of concept? Is this concept a good one or not?” So, that type of thing is very easy to test, and all I have to do is just ask people, “When’s the last time you paid for someone to help you write your subject line?” It turns out that no one’s investing in that at all. No one’s paid money. So, that’s one of those examples of an existing activity is a pain point, and it’s frustrating for people and they’ll actually go find, you know, marketing materials that will help them write them better, but they will not invest in it.

Des: What’s interesting there is that you’re drawing a distinction between two types of testing. One is “Given that the person wants to do this, is this a good way to do it?”, another is “Would anyone actually want to do this?”

Joshua: Exactly. That’s a nice concise way to put it.

Des: That type of approach comes more naturally when working on your own product, as opposed to when you’ve been hired to test something. If you’re hired to do a usability test of a travel website, you’re just going to do what everyone else would do. Round up people who use travel websites and see if they can use this one. The site can score 100% in testing, but still flop on the motivation. A well designed product that no one wants to use.

Joshua: And they’ll tell you, “Hey, you know what would be awesome? You could add this and you could do this. If you do this, I might buy it.” Then, you finally ask them that core question and then you find out that you just wasted like the last hour asking that.

Des: Is this a fundamental shift? A lot of what we’ve been talking about here is how standard UX techniques don’t map to what you’re doing when you’re designing and building software outside of a consultancy setting. Are “UX designers” meant to be consultants, whereas “Product Designers” are ones who design in house?

Joshua: Good question. You know, I call this “the agency problem.” When you’re an agency, you’re hired to come in and build something. Then, it launches, and you’re done. Your project is done. I don’t think this is effective, because engagement and actual use has become the success metric. There is a longer-term shift toward engagements where the consultancies or agencies will go well beyond launch, through iterations and improvements.

The future of metrics & measurement

Des: That leads me onto the next point, which is, what is a good metric today? If we just obsess over short term quick reward metrics, like sign-up funnels, on one hand it’s great as agencies can immediately track improvements, but on the flipside they’re bad proxies for behaviour. Especially SaaS businesses these days where the idea is: get them signed up, get them on a free trial, get them engaged, get their teammates onboard, then at the end of all that talk to them about a price plan.

Do you think the world of web analytics and business metrics is changing a bit?

Joshua: Yes. I actually think that you and I are working at companies that are trying to push this idea forward. Every part of the user experience can be cut up into small funnels and you can optimize each one of those funnels to be better. That’s what design will become: “Hey, your job is to improve the on-boarding process. Your job is to, you know, re-engage lost customers.” You know, and that’s the problem that designers will be put on and then they just have to figure out everything around that experience, to get that metric better.

That’s the way I look at the world. You know, I’m pushing hard at HubSpot to build that through all our marketing materials and then our software. In terms of metrics, I think engagement is still huge. But to answer your question, I think the high-level metrics will be at the company level and we’ll have to build software that connects those metrics with the actual touch points of the entire customer experience.

Des: What you’re proposing would be that effectively global metrics are company-wide figures, but that any individual designer will be tasked with their own set to influence? So for example, if you’re redesigning the invites screen, the metric of success is the number of teammates invited here.

Joshua: Exactly. Do you see how that completely changes a lot of people’s notion of a designer?

Des: I do. A while back I wrote about three ways you can improve a product and how you have different goals, depending on what you’re doing. You’re always shooting for one of three, two of them are easily mapped to metrics:

1. Make more people use the feature.
2. Make those who use it, use it more often.
3. Give a better experience to those who use it.

Joshua: Yes. I actually like the way you described that, because it points to the very specific metric that you’re looking to improve. “Is it a ratio that I’m trying to improve?” which is, like, of the people who are sharing, can they share better? Or “Is it like a number that I’m trying to, you know, increase?” I like that. I like that framework. A few years ago, when I last went to South by Southwest, I gave a talk called “Metrics Driven Design” and one of the fascinating things when talking about metrics in design is that it actually scares the hell out of some designers. Like it really, really scares them. That some metric will be what they’re accountable for. What I found over time is that actually makes me feel way better about doing design work. Like, “Please, give me a metric. I will go, you know, toe-to-toe with that metric and figure it out.”

To me, that’s a much more clear-cut, approachable problem than “Oh, you have to just make it look good until people are happy and they don’t complain anymore” or whatever the alternative is.

Des: Exactly. I think that’s another great example of the sort of work that you can’t necessarily procure from a consultancy, because you actually need someone who’s going to be around for long enough to understand what a ratio is and where it can go or understand where the metric is and where it can get to.

Joshua: Yes. Exactly. I think that’s going to be a huge part of the changing role of designers, that it will be kind of like, “Hey, here’s a metric. Go tackle it. Just go climb that hill.” I think designers will actually love that. You know, designers love solving puzzles and that’s all metrics are.

Des: The part of metrics where everyone got offended was the whole “41 shades of blue” type assessment. However, if the challenge was: “Make sure everyone can quickly send and reply to as many emails as they want”, then metrics aren’t offensive. Everyone is on the same page.

Joshua: The 41 shades of blue is just the perfect kind of crystallisation of the problem.

Des: Yes. Exactly. Lastly, You’re writing a book or two at the moment. Can you just give us a quick overview of what they’re about. ?

Joshua: Sure. I’ve been writing one book for four years now. I was getting good traction on the book when I jumped into doing the start-up which essentially just killed any momentum I had. As you know, startups are life consuming. When I was writing this book I realized I kept coming back to this “usage lifecycle” that we spoke about earlier. So, I’m going to release a short book first which focuses purely on that.

The key idea is that if you have a product or service that you want to bring to the world, think about your customers in terms of the usage lifecycle. Before they are actual customers, they’re in learning mode and they’re in research mode. Your task—as a designer—is actually selling. It’s teaching. It’s letting people learn about your software. You know, you can do everything from giving them a free trial to show a screen cast of someone using it, to creating marketing materials, to tweeting about it, like all of those pieces. That’s what the book covers.

Des:It sounds like a great concise book to address a specific concept really well. Thanks so much for participating Joshua, lots of good ideas there for our readers and listeners to chew on.

Joshua: Oh. Thanks, Des. Yes. And keep up the great work. I’m a big fan of your blog and I’m honoured to be one of your interviewees.

More from Josh Porter

Josh’s book “Make them care” will be released this year. He can be found on Twitter as @bokardo, and on his personal site is at bokardo.com.

We’ve been doing our best to help Intercom customers with this, explaining how to plan a good message schedule, and giving seminars focussing on communication to convert & retain customers. Thankfully it’s working.

High Stakes Communication

Mailing tens of thousands of people is really stressful. Nervous pacing, constant questioning. The worry rarely that our customers won’t like the message, product communications are very rarely bad news. The worry is that once you click Send there is no turning back. If six thousand people don’t understand what you mean when you say “We’ve moved you to the new plan, free of charge.“, then you’re gonna hear about it. Six. Thousand. Times. Email is an unforgiving medium.

The anatomy of a message

Every time I help our customers write messages, I start with questions like the following…

• Who’s the Recipient – Who are you saying it to? Business users or Freelancers? Groups or individuals?
• What are we communicating – What do you want the recipient to know now that they didn’t before?
• What’s the next action – What do you want them to do now that they’ve read your message?
• What’s the right tone – How are you going to say it to them? Is it a light hearted message, or a sober serious tone?
• When’s the right time – When will you say it? Is it right now? Is it 3 days before end trial? Do you want to hit them during work hours? Would you rather they were idly browsing on a Sunday?
• How consistently will we send it? – Will there be a string of messages along these lines, or is just this once?
• What’s the best medium – Where will you say it? In your App? In an email?

Context is king for communication. Cennydd wrote about designing with context detailing 7 variables that designers should be aware of. Often we focus on the right words and the right style, but there is far less written about the right context.

For example, here’s Delta airlines messages to me over two months…

This isn’t a rant against spam. Considering how often I fly with Delta they could send me useful mails. For example, what movies are available on my upcoming flights? That would help me plan accordingly. What’s my chances of an upgrade? Is there anything good in San Francisco while I’m there? Instead they want to tell me about gymnasiums in Atlanta. Swing and a miss. Better yet, here is the only message I did open during that period…

Why does this suck? Firstly it gives Delta dirty data. Someone in there is running around wondering why their exciting hotel partnerships is such a flop. Secondly Delta customers everywhere are either mentally or programmatically filtering Delta messaging out of their lives. This is the damage of sending the wrong message to the wrong people at the wrong time.

A Messaging exercise

Scenario: You’re a product owner who wants to get your customers engaging with your product more often, when they’re outside the office. To achieve this you’ve developed a mobile version of your app. Now you need to tell your customers about it.

The zero points method here is an blanket email shot, all registered users, right now, with a link to the mobile app. What happens next?

Some customers will receive it while at their desk. Some receive it while using the website on their phone. Some will receive it, who haven’t used your product in years. Some get it 4AM, others get it at 10AM.

Your reporting tool tells you that you had a 4.43% click-through rate and you’ll be disappointed as this was a huge stressful effort. The Delta approach is to say “5% clicked? That’s great, Just sent 19 more of those mails and we’re golden.“.

Can’t we do better than this?

Various approaches

We could split the groups by those who’ve previously logged in to the product from their phone, and those who haven’t. That would let us target a better message to each group.

We could leave a permanent message in the app for anyone using it on a mobile device so they know what they’re missing?

We could email everyone after they next log out, so we know that they’ve recently used the app, and it will be fresh in their minds.

We could write a hilarious message, poking fun at competitors, and include a funny graphic. That’ll get people talking which helps spread the word.

All of these are options that go beyond the default “Let’s just mail everyone loads” approach that most companies pick.

A remarkable message

When Derek Sivers sat down to write the code for sending receipt mails, he could gave gone for the vanilla “Do not reply to this mail. Thank you for your payment” approach, that most of the web uses. Instead he went for the funny approach above, and 13,200 people felt the need to blog about CDBaby and link up the website.

An appropriate message

Google tell certain types of users about certain types of features. For example if you receive a lot of email you’ll be offered new types of inboxes. If you receive very little email you’ll be told how you can do voice or IM chat instead. The right message for the right person.

A consistent message

Kathy Sierra uses the above image to show the difference between how companies treat leads, and how they treat customers. This happens all the time in customer messaging.

Look at how Spotify talks to me before I’m one of their customers. You can imagine the design hours that went into this beautiful mail…

So I sign up as a customer. Now they send me a receipt. I struggle to see the design hours that went into this.

A timely message

Twitter tell me about their mobile app at the exact right time. Twitter want me to use their app “on the go”, so they tell me about it just as I’m leaving. They could even go one better and only show this to those who they know have yet to install it. This would let them get a better measure of how effective the message is.

It’s not just what you say

It’s where, how, when, and to whom, and how often you say it. As Seth Godin pointed out “More people get engaged in Paris in the springtime than on the 7 train in Queens.” If your message actually matters, then surely the time, place and tone you say it in matter equally. After all, you wouldn’t drop $20K on a ring and then propose while drunk in a public toilet.

Welcome, Peter McKenna

I know two particularly talented front-end engineers in Dublin. One is my co-founder, David. Another is Peter. We’re so lucky to have him on-board. Some interesting things about Peter…

1. This is the second time he’s worked with Des. He worked with him previously at iQ Content in 2008.
2. He almost took a very different career path—he signed a record deal with Sony on his 18th birthday, but decided to go give it up and go to college instead a few months later.
3. He’s an avid street art collector and owns work by some of the biggest names at the moment including Banksy, Faile and Shepard Fairey.

Welcome, Bay Mclaughlin

Bay is a force of nature. He absolutely, genuinely, and completely really cares about helping people. Most people who say that are full of crap—I was blown away by the fact that Bay is for real! He’s joining us as Head of Business Development. Here’s three fun facts about him…

1. He worked at Apple for 6+ years, starting when he was 21.
2. He’s a classically trained pianist with two albums (which he’s sold multiple copies to Steve Wozniak!) and is an avid teacher, mentor, and advisor.
3. He’s broken 8 bones, slipped discs in his back, knocked himself out snowboarding, had chicken pox twice, mumps, and amblioplia as a child, has nearly died three times, and has had two shark and one crocodile encounters while surfing.

Welcome, Kyle Daigle

Kyle answered our call for a support engineer who can truly empathize with the problems our customers have trying to get more done with Intercom. We’ve been getting to know him better this week and I’m becoming increasingly excited about putting him in front of more customers. If you get to talk to him, I promise you’ll love him. Here’s some interesting thing I learned about Kyle…

1. He worked in Las Vegas at a 3D previsualization studio helping various touring artists prepare lighting for their shows—including Daft Punk, Elton John, American Idol Tour…
2. He lives in a converted 1860 textile mill.
3. He started coding to build a voter registration and lookup system for his town at 13.

Still hiring

We’re looking for more help with marketing, product design, visual design, product engineering, ops engineering. Contact us in confidence and we’ll talk: macey AT intercom DOT io.

You can download an mp3 of the entire interview here (40m, 50MB), or read the (lightly edited) transcript below. Please note the visuals used here were not created or endorsed by Ryan.

Des: Hi, and welcome to Inside Intercom. I’m joined by Ryan Singer, the Product Manager at 37signals. Today’s topic is going to be about building software to solve problems, by focusing on what the users really need to get done. Thanks a lot for having us Ryan.

Ryan: Hey, thanks for having me here.

Why Feature Checklists Don’t Help

Des: Let’s get straight into this. Could you tell us about Jobs-to-be-Done, and how you discovered it? And, what was the immediate realization that made it influential in what you do?

Ryan: I’ve been frustrated as a software designer for a long time, because when you look out at a lot of the software people are selling, it’s just lots of features all over the place. And it’s even worse if you’re trying to buy software. I was trying to buy some hosting the other day, and just looking at all the feature comparisons, it’s like the people who are selling this to me aren’t connecting with me on what I’m trying to do. They’re just giving me a lot of capability, and I need to figure out how to piece it together myself. I’ve always wanted to be the opposite of that somehow. I always wanted to make products where the purpose of the product is really clear, and it really connects with something that somebody’s trying to do.

The core idea that turned me on about Jobs-to-be-Done is that products are also services. They’re not just a bunch of features that people pull into their lives to get from point A to point B, and there’s this idea that people are always trying to make some sort of progress. And, the only reason that people bother to buy your tool, or use your software, is because they are in a specific situation and they’re trying to make some progress—get from here to there—and they’re struggling to do that.

So, that point of view kind of gave me the language, or it gave me some words to understand something that I, kind of, understood at a gut level. I heard about the terminology in a Clayton Christensen book called The Innovator’s Solution. And I’d been hearing it here and there, and then there was a podcast from Critical Path, where Horace interviewed Bob Moesta, who is one of the guys who created this way of thinking.

A big lightbulb went off when I heard that podcast. It was like: here’s the real story behind this way of thinking. So I got in touch with Bob and have been able to get to know him a bit, and learn from him a bit. I still feel like I’m at the very corner, just learning a little bit about what he calls Jobs-to-be-Done. The core idea is that people are trying to make progress, and my job in making products is to give them something that will really help them to solve their problem. Not just to make a bunch of cool looking stuff, or something that has a bunch of features.

Des: What was it like to get it adopted or into your workflow, or by a design team? Did you have to sort of spread the word, or was the take-up pretty good?

Ryan: Everybody likes the idea, but I wouldn’t even say that I’ve gotten it adopted, and I’m also not sure what that would look like. You know, I think if you look at it in a more strict fashion, what Bob is often talking about is doing some serious research to get to know what the customers are actually trying to do. And, we did a round of that research for a Basecamp, and we were surprised by some of the answers.

But, I can tell you that we aren’t doing that research all day. And, honestly, the DNA of the company is to not do research. Our company DNA at 37signals is make things we want, and to make them the way that we want them. We’re lucky in that some of the things we want, other people want too, you know? That’s how Basecamp came about; it’s because we had that problem ourselves, and same with our other doable things.

So, in a way, we haven’t adopted it at all, and at the same time I think of this question, what is the purpose, what is goal? What is the definition of progress? Why is somebody using this and where are they trying to go with it? This new point of view has kind of hardened that, or at least given me more ways to talk about that. It still comes up mainly when I’m talking to the other folks about an idea. It’s not that we have a process or a new kind of conveyor belt in our factory, where we can just put things through an algorithm and get different results out.

Des: So it’s more like a new perspective from which you can speak?

Ryan: Yeah. It’s especially a good way to push back on any kind of development that is unclear. You know, if there are some features that we’re working on, or some interface that seems cool, we can say “What is the real purpose here? How is this helping people?“

Des: That’s interesting. I’ve read in previous interviews that you’re working on a new product that’s a membership application for a non-profit?

Ryan:Yeah.

Des: When you’re building a new product, how do you apply this line of thinking when you don’t have active users yet?

Ryan: Well, I’m an active user, and I’ve got friends who are active users. So, it’s not like I’m really starting a business. It’s something that we need, and there’s no good options out there. Man, the software out there for doing automatic member donations, like monthly donations to something, those software products all suck! I looked really hard, and my first idea wasn’t to build something, it was really hard. And they’re all terrible!

If you look at fundraising software or donation software, there’s 2 classes. One that is very enterprise, for big national non-profits where it costs thousands to get set up, and you track every single donor, so that you can harass them by phone and send mailings all the time. Then, the same companies also have “low-end” offerings, but all they do is take their enterprise product and put a monthly price tag on it.

Then, there are a lot of social fundraising tools which are social platforms. There’s no simple way, for a representative of an organization to just take somebody’s money every month, or from the administrative side, just see their members and how much they’re giving.

It’s amazing how poorly the existing options handle these basic needs, to see how many numbers you have, and how much they are paying and if their cards are going to expire. I have a couple of really clear jobs to be done, and the products just don’t cater for them.

Des: You could have designed this product five years ago. Do you think you would have designed it differently?

Ryan: Not at all. It is very easy for us to take something like Jobs-to-be-Done and think of it as this transformative thing. For me, it’s putting words onto something that I didn’t know how to describe before.

I think that whatever it is that I’ve been doing, in a successful way, with software design over the last 10 years has been this kind of thinking. Where it’s all about standing in the customer’s shoes and thinking “What do they need in order to make progress? What are they trying to do?” And this is just a simple common-sense notion, to intuitively feel yourself in their shoes, understand their situation and where they’re trying to go. We feel like we need Jobs-to-be-Done to flush it out and give us some ways to talk about it, because just saying it plainly is too obvious, too common sense.

On UX Process & Deliverables

Des: Did you ever consider techniques like personas or user journeys, or any of those UX design methods?

Ryan: That that stuff is all terrible. The problem with personas is illustrated really well with an example: You’ve got a couple and they’re middle-class Americans. They’re in their early 30′s, and they have all these attributes: the car they drive, ethnic background, the city they live in, etc. And then you ask “Is this person going to go for pizza? Are they going to go to an upscale Italian restaurant, and have an expensive entree and a romantic evening with wine?”

The attributes don’t determine that at all, because on Monday night, the couple orders pizza. And, on Friday they go to the restaurant.

Des: So, you’re saying that knowing details about a user is useless independent of knowing what they actually want to do?

Ryan: That’s what Clay talks about in Marketing Malpractice. He talks about how your attributes don’t cause you to do things, it’s the intention that you have, where you’re trying to get a certain kind of result. So, that same couple, who has this exact same persona, on Monday night, they’ve had a long day at work, a long week ahead and it was a busy weekend of running errands. And, it’s Monday night and they just don’t feel like cooking, and they just want to take a break and have an easy night in front of the TV, because it’s been a long day already and the week is just getting going. So, they order pizza.

Des: Do you see any role for understanding the attributes of the user? Say, their level of income influence the manner of when they have a consideration set?

Ryan: There might be experts who can comment on that, but I’m not one of them. From what I’ve heard, you can do slicing and dicing in terms of who is going to be your best bet to speak to you about something. So, if you’re going to be selling the newest, latest, greatest home sound system, where you can stream all of your Internet services through your wireless sound system, I don’t think that the retirement home would be the place to market that.

That’s kind-of common sense. So, I think there’s a basic level of segmentation that makes sense that way. Honestly, since I’m not a marketer, I think the whole thing when you’re looking at jobs is that you’re looking at causality.

Des: Causation is the driving factor. It may be true that like, Rolex customers all make over a certain bracket, but that’s not the trigger, because there are plenty of people who cross that salary threshold, and still don’t think a Rolex solves a problem for them.

Ryan: Absolutely, yeah.

Des: I find your take on the User Experience side of things quite interesting. You’re one of the more prolific people when talking about software design, though I know you never identify yourself as a UX designer. It’s interesting that you don’t adopt any of the practices there, from wireframes all the way down to personas.

Ryan: The things that get called User Experience come from the agency world. It really seems to be like that. Every time you meet people who are doing all of these UX methodologies they come from the consulting world. My background isn’t in the agency world; it’s in the product world. The whole game changes when you don’t have the pressure of delivering to a client on time, or trying to convince a client that you’re worth hiring or worth sticking with.

For example, if you’re working on products, and you’ve got a really capable team that can prototype things in real code, of course you don’t need wireframes, because you don’t need to get sign-off on something from a client.

Des: So UX is about solving agency-client dynamics, more so than building great software?

Ryan: Yeah, I really think it’s like that.

The whole UX world was defined by agency and client services people. People like Adaptive Path defined what UX is, and those of us who didn’t identify with that—but wanted to make software products—we kind of grew up in a world where the only way to talk about making interfaces was to use all this agency-client services stuff.

And I think that’s kind of backwards, because the fundamental challenges that we have are: how to make a good product—and whether you are doing that for yourself or someone else, you have the same fundamental challenges—how to define the problem, how to deal with all kinds of constraints, how to get the different roles—a designer, developer, support, strategy, all that stuff—working together.

If you put the product problems in the center, then adapt that to deal with all of the trust issues, the communication issues, and payment issues, and all that stuff. All that stuff is a corruption of the core process. If you all trusted each other and were working together on the same side of the table, you’d do it one way, but because you have a few people who are skeptical you have to keep gaining the trust, trying to prevent them from asking for changes, all that stuff.

Then, you have to corrupt your process a little bit. Those processes, where you have to learn how to do sign-offs and stuff, those all became central to product design. They’ve become the definition of UX: You have to do all these different stages, wireframes, stuff like that.

Des: It’s a heavy bit of baggage to bring on to a product team, if there’s no client involved.

Ryan: Right. You don’t need all that stuff. At the same time, I understand why it’s like this, because they had a big problem; you know, there were a lot of people in the agency world. And it was valuable for them to articulate the way they solved the problem and their solution for solving it. And, the thing is, people in my position, who just make product and aren’t in a client/service model, we haven’t offered an alternate view. So, it’s totally understandable that the sort of agency perspective on things would be dominant, because there really isn’t another perspective you can pick up on things and learn.

How to expand your product

Des: Let’s move on to sort of a higher level. As a Product Manager, when people are using a product you designed in a way that you didn’t intend it, do you see that as a new job the product can do, and should be improved for? Do you see new product opportunity? Or do you just think it’s interesting that people are using this for something we didn’t design it for, let’s leave them be?

Ryan:: I think this comes back to the thing about DNA. Some companies have the DNA for chasing opportunities, and it seems like at 37signals, our DNA is to find the problem ourselves, and we don’t have to chase it through measurements, interviews and statistics, and nail it to our own satisfaction. I think that cuts pretty deep for us, to the extent that if people were found out to be using our tool for a totally different purpose, if we can’t really identify with that purpose, we’d have to be really pushed by, let’s say, falling revenue or something dramatic, to start designing around that. We have a really strong preference to stay close to what we know, from our own experience, even if we’re seeing a lot of success in another direction.

We’re lucky in that the main use of Basecamp is very clear. People who are client/service firms, who need to manage their projects, it’s just a no brainer that this is good for that. And people who work with a fair number of other people, and need to collaborate on projects, who are mainly interested in communicating their status on projects and not tracking dependencies, like that. Basecamp is just a really good fit for that.

The thing is that there is no end to the number of problems that you can solve. There’s just no end to it. If you are the type who wants to look for, and chase, more and more opportunities, you can do that all day. Especially when you’re good at making products. I mean, we’re pretty good at it, and I think that if we were really chasing after lots of different opportunities, from where we could make something happen, really nail it for an individual use-case, we could do that all day. But it would dilute our focus, and this is always the trade-off. There is so much cool stuff that you could do, but how much of it do you want to do?

Des: And, also, how cool will it be when if you have to do all these things in parallel?

Ryan: Exactly. I’ve been thinking about this lately, because I really like to focus strongly on the fundamentals; on really getting good at solving problems. Because then, whenever a problem comes up, we can build something pretty good to solve it. The main question isn’t whether or not there’s an opportunity somewhere, it’s more like we know we have the ability to work well together, we trust each other, we can build great things together, and if we’re going to build something to target an opportunity, then we do it in a diligent, very, very focused way. You know? So, rather than building 10 vertically narrow different versions for different industries of Basecamp, or something like that—we could do all that, but is it worth it? I’m not sure.

I would just rather keep doing really good work for the cases that we care about and then, if the landscape changes, and there’s a new idea that comes up that we’re excited about, or we see usage start migrating away towards something else… it becomes a concern then. Then, we can always take a look at those opportunities and decide what to do, but I just feel that you can go crazy with so many opportunities out there, it’s like you brain turns into Hacker News.

Des: What would your stance be for plug-ins/modules for web software? It’s alleged by a lot of thinkers out there that you should maintain a product core, but make it extensible to different domains through plug-ins.

Ryan: Well with Basecamp in particular I’ve noticed that you can distinguish between projects that have an end (i.e. a definite point at which they’re over) versus things that are more like an ongoing process. If we really wanted to, we could clarify this for people and have recommended ways to use it. You know how you open up Pages, you have these different templates? You’re using all the same bundle of functionality, but you’re putting it together in different ways: to make a business letter, or a newsletter, or whatever.

Des: I guess the way you would do that, while keeping a broad product, would be to ask “What type of problems you are trying to solve?”

Ryan: Yeah, what are you trying to do? Are you trying to plan and coordinate work? Are you trying to record information for later, to protect yourself… what is that you’re trying to do? But again, this is all a bit speculative, and what I meant to illustrate is that there are different ways that you can use the tool to different ends without going all the way down to building something that is really narrow for a specific vertical.

The role of a product manager

Des: Lets talk about the role of ‘product manager’. What problem occurs in a company that causes them to need a product manager?

Ryan: I had the experience whenever I was at a cocktail party and somebody asked what I did at 37signals. For a long time after I got this title, I’d say “Well, my title is Product Manager, but I’m not sure I know what that means.” And, maybe even a couple of years went by before I stopped saying that, because I know better what it means now. But, it took an experience to clarify it.

What I noticed is that we reached a point where one day I looked around at what was actually happening. Actually, I took a bit of a break from managing projects. I took maybe a month or two, where I stepped away to really focus on playing around with iOS and learn some things. And, when I came back, I noticed that things weren’t going totally smoothly.

Des: So, then you knew what your job was.

Ryan: Well, then I tried to find out what my job was. We really value self-management at 37signals, and it’s been experimentation over the years just to see how much self-management can people really do, and what can you get out of it? In some areas, it’s been really successful. I mean, there’s a lot of self-management happening at 37, but at the same time, what I noticed was that despite a lot of success with that, projects simply were not getting shipped. I wanted to see people picking up an idea, developing the concept, implementing it, reviewing it, changing it as necessary, reviewing it again, and then deploying it. And, I wasn’t seeing that happen.

So, I was asking myself “What’s missing? Why isn’t this happening?” And I realized that what it really takes to ship product is coordination. Somebody has to actually pull the people together, and get all the different roles to connect with each other. Whenever you build some product you’ve got to have design, you need to have programming, support has to know about it, it has to get QA, it has to be reviewed by people who can say no to things. All these different pieces have to come together.

And, if somebody doesn’t actually take care to schedule everybody’s time, so that the right people are available at the right time, with the right context, to work together and make all those things happen, it just doesn’t happen on its own.

So, I’ve come to see it in a big way as a coordination role. Where I’m taking a sort of strategic point of view, where I understand the value of what we’re trying to do. And, I also understand the value versus the cost of how much time we’re willing to spend on it. As an overall frame, in that, to get the different roles and the different people, so that they can each contribute what they need to contribute, and the thing can keep steadily moving and eventually get deployed. I just learned that that doesn’t happen by magic. Somebody has to make that happen.

Des: Like the conductor to an orchestra, they themselves don’t play the music but if they’re not there to coordinate then the tunes won’t get played.

Ryan: The review is a really big part of it too, I have to say. The coordination is huge and then, at the same time, there also needs to be somebody—at least the way that our company is—somebody needs to take the role of editor or grand editor, or curator. At the end of the day, that’s always Jason at 37signals, but I also play that role. And, that’s important to have each step of the way. Because it’s very, very easy to get inspired to build something and to release it.

But, man, if you don’t watch out to curate what you’re releasing, soon you’re going to accumulate a lot of stuff. You know you’re going to have a lot of settings and a lot of options. And it’s so important to have somebody saying no, and to really curate what goes out, so that the product stays coherent and stays simple, and it always has free space in it for something new to come later.

Different Designers for Different Jobs

Des:Do you think you could hire a second product manager, based on your experiences of the role now?

Ryan: I’d love to replace myself and I haven’t figured out how yet. So, that’s an open question.

One thing though that I did learn about is that years ago I didn’t really differentiate between different types of designers. As time has gone by I’ve become more sensitive as to which person I can ask to do which kind of design. Some people who are really strong with what you would call interaction design. They’re really good at positioning buttons and elements on the screen for functional reasons. Other people who are really good at more of an artistic kind of design, it has to do with color and typography and art.

There’s a third person who is really good thinking about the right words and the right copy. And I find that you’re lucky when you get all three of those together at the same time. But very often you find it in different people, in combinations. Now what I’m learning is that there are certain people that I can bring in, I can hire them, even though they’re already in the company.

Des: And you’re hiring them for a specific skill or perspective, right?

Ryan: Yeah. Because I know that the job is to bring a little bit more visual style in, or to bring more clarity to the text, or to put some UI together that’s going to really work well. I’m even noticing this on the programming side too.

I used to think that we just had programmers, and now I’m noticing that we have some programmers who like to work alone, and come back with a stroke of genius type solution to a difficult problem. And that there are other programmers who like to stay close to the rest of the company, and communicate their status on a daily basis. There are other programmers who don’t really like to take risks, so they really like to take every step possible to avoid bugs.

Other programmers are really progress-oriented, and they would rather make some big leaps, without checking every stone under their foot along the way. Where there may be a few issues in the end to clean up, but they really move things forward. And, again, it’s a hiring criteria, even though they are already in the company, you still have them for a certain project.

Becoming more sensitive to that has become more interesting for me lately. Nobody is 100% of one thing, but becoming more aware of somebody’s strengths, I think that if I were to hire somebody new to the company, this would be more on mind than it was in the past.

Des: So if you know you are re-architecting something fundamental, you probably want people who are risk adverse, and won’t make any mistakes. Whereas, if you’re going to build a new product, you know you are going to hire specific people who can move mountains pretty quickly, but there might be some fallout along the way.

Ryan: It’s also a challenge, because people are changing all the time, and I don’t want to put anybody in a box. There are some people who come in, being really artistic and not very clear with the technical interaction type things, but they might be interested in slowly learning it over time, from the others. It’s also somehow really important to keep a fresh state of mind, when you’re looking at everything in the moment, instead of the box you put them in six months ago, you know? It’s an interesting challenge.

You can read more from Ryan at his personal blog: Felt Presence, his posts on Signal vs Noise, and follow him on Twitter as @rjs.

The faustian bargain of the internet is that you can swap your credibility for attention anytime you want. It’s not hard to get your name/product/company/brand well known, even if you’ve done nothing of note, but getting it well known for the right reasons is a different challenge.

The well known growth hacks used by sites such as SocialCam and Viddy require users to provide Facebook authentication to view a video. It works really well if your measure of success is Accounts Created. Here’s how well it works:

High and to the right, right? Who’s gonna argue with that?

Users will. Facebook will. Trying to hack social sharing pisses off the customers you trick, and the network you use. Lets see how that worked out for them:

This is the problem with false proxies. Someone in the company decides that accounts created is their metric of success, so the team works out ways to hack that number. Over time people lose sight of what’s actually important for the business.

Google+ growth-hacked their way to 170 million users, by putting interstitials in Gmail where the easiest way out of it was to click “Okay” which both set up an account and connected you with friends. Had Google+ focussed on a metric of “Users who choose to go to Google+ and share at least 2 updates per week“, they would have focussed their efforts on delivering value to users rather than popups that drive numbers.

Hacking a Metric

Lets say you hire an analytics consultancy for your project management app. They’ll dig deep into your data and come out with something like the following:

Users who have invited 2+ teammates and posted 3 updates will upgrade to convert to paying users.

A Growth Hacker hears that and thinks “Sweet, all we need is a to get everyone doing this. Let’s go…”

What happens next? Users click the button, and the metrics go up, but the upgrades don’t follow. Lots of things correlate with users upgrading, but artificially triggering the correlation doesn’t cause anything. If it did, fires would spontaneously break out near groups of firemen.

What Harm Does It Do?

Tricking your users just so you hit your metrics causes long term, if not permanent, damage. Bill Bernbach famously said that “Great advertising makes a bad product fail faster; it gets more people to know it’s bad.” This principle applies equally for web applications. Tricking potential customers into doing something prematurely, whether it’s creating an account, tweeting, or completing a task has the same effect. They’re likely to do it once, leave, and never look back.

Meaningful Growth based on Meaningful Metrics

A meaningful metric captures a moment of value for the customer and the business. There should be no way that it can increase without both parties receiving value.

For Shopify, the total number of stores created is a bad metric as it can increase with no new value to the business. Alternatively, for a company blog things like pageviews or shares are equally bad as they can increase with no new value created. This is how the blogs evolve into junky list posts, cat pictures, news-jacking, and other crap. The metrics will go up but with no new visible new value to the company, and often some hard to quantify brand damage.

Shopify probably track something like stores with over $1000 in monthly revenue. That is a good metric as it only increases when proper customers are acquired, and barring fraud, increasing this figure is guaranteed to be good news for the company.

The danger of bad metrics can be seen in the old adage “What gets measured gets done”. Measuring irrelevant figures and your team start performing irrelevant tasks to increase a number that doesn’t really matter. Seth Godin said it best: “Gaming the system is never the goal. The goal is the goal.”

It’s a value problem

You know you have a value problem when you hear the following:

• I just haven’t gotten around to it yet.
• It’s pretty expensive.
• I will once I get the time.
• We can’t afford it yet.
• That’s not important for us right now.

You’ve heard these before, right? They all mean the same thing: “I don’t see the value“. You see, cash isn’t the only thing businesses spend. They spend time and focus too.

Using your product or feature has to be worth the time, focus, and money. Money is usually the least of the concerns. $49 per month doesn’t mean a whole lot to a business dropping $20K per month in salaries alone—and that’s a very small business.

Solving a value problem requires strong positioning. It comes down to how you sell your product, how you frame your offering. An Audi looks expensive at a car dealership but looks like a bargain at a yacht show. $29 a month is pricey for “5GB of file storage” but great value for “the certainty of keeping your family photos safe forever”.

The toothpaste industry only really took off when they started selling “beautiful teeth” as opposed to “prevention from gum disease“. We all know flossing is a good idea, but we’ve yet to hear a similarly compelling pitch for it.

Why Should I Buy Your Product?

Understanding why your customers buy your product is the key to positioning it properly. Is it “peace of mind for your most vital files”, “painless file-sharing for business”, or a “easy way to access your torrents”. All of these describe the exact same product, but they appeal to different people at different price points.

Real example: A friend was having no luck pitching a product as “all your online files in one place“. That sounded good but simply didn’t solve a problem people related to. She heard lots of answers like “This sounds great! I’ll give it a try in a couple of weeks”.

After digging deeper, she found a real pain point that her potential customers experienced quite often. She re-framed the product as “When your favourite app gets bought and shut down, we’ll have your back“. That resonated with her market. Not a single line of code changed, but all of a sudden this product was a painkiller. And people started buying.

Key idea: Understand that it costs more than just money to use your product. So when you’re asking your users to do something, frame it in terms of their needs and desires, not your features and bullet points.

Tip: Customers who have bought your product recently will describe it far better than you can. I’ll give the last words to a man far smarter than any of us.

They don’t know where to start or when the confusion will stop. So they walk away.

Some tasks are inherently complex. Sometimes there is no one-click solution. But complex problems don’t always need complicated solutions.

A complicated solution looks like too much work; it leaves users stuck, they either don’t understand the questions, or they’re wary of what they’re doing. So they skip it.

Three ways to keep complex interactions simple for your users:

• Divide the task into simple steps, offering inline help and example inputs for every point.
• Use a fill-in-the-blanks technique to make the complicated interface read like English.
• Offer smart defaults and templated solutions that users can then edit.

One heroic example of this is the web app ‘If This Then That’ (IFTTT), which uses 7 steps to create a rule, but always asks you easy questions. This product let’s you program rules based on what happens in your web products.

Lets say you wanted to create a rule that sends all your starred items from Google Reader straight into your Instapaper account. This is a complex task, but thanks to the good folks at IFTTT, it’s not a complicated solution. Look how easy it is…

Real Example: An Intercom customer running an advertising network had a problem where users would sign up but never start a campaign. He set up Auto Messages to talk to these users and find out what went wrong. They told him that it was too complicated, too many questions, and hard to figure out.

He changed it. Now his new sign ups are given a campaign ready to rock, with a budget allocated, imagery uploaded, start dates set, etc. It’s much less daunting to edit this existing campaign than to create one from scratch. A massive win for him & his customers

Key Idea: Make complicated forms easier to pass by breaking them into steps, using plain English, smart defaults, and ready-to-edit configurations.