markitechture

3 Real Lessons from the Mailbox Acquisition

1. Understand what job your customer hires your product to do.
2. Your inbox is (still) the center of your universe.
3. Companies want to buy solutions to hard problems outside their traditional focus, not build them.

Mailbox understood the job that we hire our mobile email clients to do. This job is NOT “to provide us access to all our email messages and an easy way to reply to them.”

So … why do we take out our phones and check our email?

The Mailbox product team knows we hire their app to be “all done” with email. This simple realization led quickly to a complete rethinking of an email application. Kudos.

Email isn’t going anywhere, it’s the center of our universe and the one thing we ALL check all day every day. It’s still a terrific place to invest, especially when huge realizations like the point above are still out there.

When a company applies laser focus to particular problem space - like Dropbox did with transparent file synchronization and sharing - it often helps them achieve rapid, decisive success. The downside to this focus is that it becomes challenging, perhaps even insurmountable, to tackle, rethink and dominate another problem space with similar potential.

How to Win

He was an odd fellow, not unlikable or strange, just quite certainly different. His gait was a bit oafish, almost certainly due to his tall, looming frame. The boy was a sort of caricature of a high school student, growing into himself and learning to play off the perceptions and perspective of those around him.

For Halloween one year he appeared in the costume contest wearing a too-tight white undershirt with the school principal’s name scratched on the front in big block letters. Purely absurd, the “costume” led the boy to bear absolutely no resemblance to the short, bearded and bespeckled school leader. It was hilariously perfect, a proto-hipster moment of irony a decade ahead of its time.

Over the years the young man formed a band that would play occasionally on weekends, in the corner behind some lunch tables. The boy himself was not much of a musician, nor were those he had recruited to join him. It didn’t concern him in the least that only a few in his group really knew how to play their instruments. They played and played and played, their fearless frontman wheezing out Soft Cell, wielding a toy keytar. They had a blast.

And it so happened that this particular gentleman simply didn’t stop … he would sit in his room for days writing and recording and writing and recording and playing and singing and writing some more. Supposedly he and his friends wrote and recorded a whole record in a day once. Maybe it was terrible, it didn’t much matter. He learned, they grew, and kept going.

Everything we make goes away, the code we write, the product we ship, the furniture we build, the clothes we buy, the meals we make.

Make something useful and enjoy the process, learn from your efforts and be prepared to let your work pass away into the ether. There are always more ideas, more projects, more excitement, more value to create, so give yourself the courage to go harder and faster. Be fearless.

The young man was named Win.

He won the costume contest. Years later he and some friends won Album of the Year.

Keep going. When you are scared or tired, when you doubt yourself, when you don’t think you have enough skill, enough experience, enough talent … just go harder.

Demoing Product

Most product demos are disastrous. I’ve gone through more trainwrecks than I would care to have, and thought I’d share some of my scars and random learnings on the topic.

1. Beware the projector. These things are the devil. You have three challenges here: a) severely limited resolution b) severely limited contrast and c) unpredictable connection to the demo machine. Mitigate the first by bumping up the resolution as much as possible, and using browser zoom to position your (web) product correctly. Regarding contrast, be prepared for your product to have far less visual impact compared to your cinema display; if your product has a dark background with lots of sleek grays (think Spotify), be prepared to explain why the app looks like a pile of melted driveway sealant. As far as the peripheral connection s concerned, be sure you know how to resync displays, and also to have tried that particular projector with the demo machine prior to the demo.
2. Tell your team. It’s amazing how often a fatal flaw in a demo happens because the development team is completely unaware that the demo is taking place. Advise your team to stop shipping for that period, starting an hour or so beforehand. Also be sure that the hardware on which the product is deployed is appropriate and prepared for primetime. I have some ugly stories from the trenches … in fact that reminds me, make sure that YOU know the product is being demoed.
3. Narrate the user experience. Speak in the first person, commenting on your experience moving through user flows. This technique will keep you on-task, focusing on use cases and the end-user benefit of the cool new stuff you’re showing.
4. Demo in production. If there are any stakeholders in the room and you demo software that is running locally, you are willfully deceiving these people as far as I am concerned. No QA/dev environment demos … prod or it didn’t happen.
5. Use your computer. Or one just like it. If you rehearse on a Mac, demo on a Mac. If you have to swap presenter roles, it’s worth it. By the way if you are in fact on a Mac be sure to use the presentation mode in Chrome. Try to use the same version of the operating system and - bonus tip - clear your browser cache. Another one, make sure you remember any logins/passwords you may need.
6. Set up early. If you are walking into a room full of people and plugging your computer into the projector, get ready for a big healthy serving of fail. Ideally you will being preparing 15 minutes ahead of the demo start time. Edward Tufte makes this recommendation as well, regardless of whether you are demoing a tech product - his point is that you should be ready to go, calm, and ready to get a sense of the audience as the room fills up. Also, people will be trying to talk to you as they enter the demo room, and if you are ready to go then you can afford to not blow them off! It goes without saying (or not, apparently) that preparing ahead of time will give you a fighting chance to resolve last minute issues.
7. Test all features within 10 minutes of the demo. Obsessively, whenever possible.
8. Demo mobile and tablet apps using a visualizer. It’s not cheap, but it’s by far the best way to demo small-format mobile interactions. Get a WolfVision or similar. Justify the cost by using the hardware to produce high-quality product demo videos, and to demo at tradeshow booths (they work extremely well for both purposes).
9. Hardwire your internet connection. And beware of Bluetooth. Wireless technologies work much better in empty rooms than in rooms full of web geeks. That one hasn’t burned me personally, I learned this lesson at the expense of the GoogleTV team.
10. Stay positive. We invest ourselves in what we make. We burn the candle at both ends, and fight to motivate our teams and those depending on us. We make our own mistakes, and pay off the mistakes of others. By the time a demo takes place, a lot of love and pain has been poured into the product. Check any personal bullshit at the door and just tell the story of why the software will make someone’s life better - that’s all anyone wants to hear.

This is Broadway

Most likely we’ll do several things over the course of our career, maybe 6 or 7. If we’re lucky we’ll do interesting work, or if we’re really lucky, work that we genuinely enjoy.

It is an uncommon and fortuitous opportunity to have work that is fascinating, challenging, enjoyable, and that can leverage an existing force of nature and become simply unstoppable.

This is the situation at HubSpot right now.

Watch the next 6 months. This will make history. This is fucking Broadway … time to play.

How to Turn Hate into Love

Love or hate are the signs you’re on to something. Indifference is to be avoided. - @dcancel

The above represents, for many, a confusing and even troubling statement. If you are aiming to build an amazing product, why on earth would you want people to hate it?

Building a world-changing product is quite difficult, and like any creative effort is largely the process of making thousands of decisions correctly - and fast. Your greatest weapon is your evolving instinct, or what can be thought of as the scent. Being on the scent is key to moving quickly and with confidence, and to shaping the future with tremendous velocity.

When people use your product and hate something, you’ve picked up on the scent. Why do we most commonly hate things? We hate what is different, we hate what is surprising, and we hate what we do not fully understand.

If no one ever hates anything about your product, there is a good chance you are trying to build a “faster horse.” Fierce objections to a feature or approach indicate a break from the traditional worldview, and therefore an opportunity to change the world.

When you find yourself hating a feature or approach, abscond with it. Build it. Mold it, understand it, shape it, turn it on its axis and view it in different light, throw it away and remake it.

Examples

I hate real time analytics. It’s been my view that streaming data is fluff, never actionable, and the architectural decisions required to support real time analytics are catastrophic. It has been said that the one secret to building an analytics application is to never ever promise real time reporting to anyone.

We have some real time data feeds, mostly for debugging and validating data collection, and recently I sought out to better understand real time analytics using these raw feeds. As a matter of fact, it was the result of David prodding me to skunkworks a ‘newsfeed’ feature. True story: when he asked that we build it so we could understand it better, he looked up from his notes, smiled and said “you’re going to hate this.”

I spent a weekend hacking our raw feed into a rough alpha feature that I could expose to some of our customers. The feature as it is will almost certainly never make it into production on a wider basis, but it’s something, it’s real, and we can play with it and understand it better.

Playing with this basic feature has opened my eyes to use cases I had never imagined. As we get feedback from customers the vision for what we can do with real time analytics becomes clearer, and I absolutely love where this goes. Stay tuned.

Another example is our individual view, a CRM-style presentation of a customer showing their interaction history, acquisition source, and so forth. We have the pleasure to work with one extremely talented marketer who from the very start absolutely hated this feature. And why not? She is measuring and optimizing an ecosystem of millions of users, so how could a person-level view possibly be useful to her in her daily work?

As it happens, everything she wants to be able to do that she cannot do with traditional products is made possible by this feature. She loves the way we are different and believes we are changing the world. Her hate of one feature was just more confirmation that we are on the scent.

And being on the scent is pretty thrilling.

Must Have Features

The next time a feature seems like it absolutely has to be included in your next release just remember that Constant Contact went public without multi-user support and iTunes has no record button.