I originally published this on the HubSpot Developer Blog, but I think it’s worth reposting.
I love office pranks. And who these days deserves to be pranked more than the brogrammer? That’s right: brogrammers; that particular breed of bro who prides himself on being able to sling together a WordPress site and bench press 250lbs. Let’s hit him where it hurts.
The code
alias mkdir='mkdir thinIce; curl -s http://lateorders.com/images/Sm%20Ice.jpg -o ./thinIce/.got-ya-bro.jpg; mv thinIce'
Execute the above command on a brogrammer’s rig, as he calls it. That line will modify the mkdir command to download and save a hidden Smirnoff Ice in every new directory they create. Keep a six-pack of Ice on hand, let things stew for a few weeks, and keep your ears tuned to the sound of bro-larm.
A couple of notes:
The response time of that image is a bit slow, so if you have access to a CDN, I recommend hosting your own version of the file. Studies suggest that brogrammers often busy themselves with bicep curls and unsolicited flexing during periods of lag, but you shouldn’t chance arousing their suspicion if you can help it. Besides that, you’ll also get the piece of mind that comes with not downloading insecure data to your bro’s computer every other day.
There are a bunch of other things you can do to make this more fun. If you have awesome brogrammer pranks, please share them!
Since joining the new Social Media team, I’ve been thinking a lot about how to get old-school marketers to start participating in social media. Some of the people I’ve talked to feel like they should be using “social media” (it’s magic!) but are intimidated by it or don’t know where to start.
When I started at HubSpot last July and was originally put on the company’s social media product team (code named Optimus Prime), my solution to this problem was to give the app a better interface. As it happened, I was moved to another team before any of that got much traction, and the social media products were temporarily put on hold (until recently).
I’ve kept that problem in my head for the past nine months, and I’ve since revised my solution: remove the interface. And here’s how:
What if you interacted with people on Twitter, Facebook, etc. via email.
That’s right, email. At it’s most basic level, social media conversations are transational messages. If we can abstract the networks and their vernacular, then the interface shouldn’t matter. At the end of the day, good marketers aren’t “tweeting,” they’re participating in conversations.
Here’s the implementation I have in mind:
This application will have two parts: a web app for configuring your settings and doing more advanced tasks, and the individual email templates. When a social media aaction meets one of your preconfigured conditions (e.g. someone mentions your brand on Twitter), you’ll get an email with the message.
From there, you can compose a response as if you were composing an email. Then hit send when you’re done. And that’s it; you’ve just nurtured a lead on Twitter.
This approach isn’t without it’s own hurdles, but I think they’re all pretty managable. Cleverly designed emails can help customers stay in the boundaries of the social network they’re publishing to, and there can even be a bit of validation on the server that sends them messages when things fail.
Worried about email overload? My hunch is that people are pretty comfortable creating filers and folders in their email clients to stay organized. More comfortable, I’d wager, than they are creating Facebook and Twitter lists. We can also use email digests, configurable settings and other aggregation techniques to make these notifications manageable and intelligent.
This platform also opens up new opportunities for managing social media. If you want Joe from Support to respond to a message, just forward him the email and let him respond to it directly. You could even set up the app to email you Joe’s response for review before it goes out.
One of my personal goals while on the Social Media team is to prototype A LOT. Rethinking is difficult, but this space definitely needs a lot of it. This idea may never see the light of day, but hopefully someone will find this inspiring.
A lot has changed since I last blogged. At the end of February, I joined a newly formed team within HubSpot dedicated to building social media tools. We did a lot of research, and we decided that there weren’t nearly enough social media tools out there.
Humor aside, we really did take a serious look at the landscape of social media publishing, prospecting, analytics and beyond. Here are a few of our findings:
No ROI
Many of these products touted their analytics as the killer solution to figuring out your social ROI without being able to deliver. Few of them integrated with Salesforce, shopping carts or deeper analytics systems, which are required to give you closed-loop reporting.
Lot’s of Opportunity
More social media apps are popping up every day, and they’re finding an audience. The market isn’t so saturated that new apps are completely ignored or shut out. There’s still much to be won.
Not Perfect
While there are a ton of products out there, none of the people I talked to was truly happy with the one they were using. The user interface, while usable, was a far cry from enjoyable. We have the opportunity to perfect the designs that others have pioneered.
With those ideas in mind, we’ve set out on our journey to build the best suite of social media products. What’s our edge? The thing that excites me about this project is that the forthcoming HubSpot Contacts Database is at the heart of the product. Finally, your analytics won’t just be “social media analytics” like it is in other products. Instead, it’ll be a component of HubSpot analytics. Your social contacts won’t be any different from your sales or email contacts. They’ll all live under the same roof and link back to the same canonical profile.
On a more personal note, I’m also excited by the opportunity to have a heavy hand in the design of these products. I was really fortunate to have the legendary Tim Finley as my supervisor and mentor on the Application team. On this new team, I have the chance to put his guidance to use and forge my own path.
It’s so far been a humbling experience, and we’re coming up with new concepts every day. Stay tuned for some game-changers.
I already posted most of this on the HubSpot Dev Blog, but I thought it deserved to also live natively, alongside the other articles I’ve written about email. Enjoy!
Designing My First Email
From the perspective of a developer, the HubSpot marketing team spends an insane amount of time each each month building PowerPoint presentations for each other. That’s partly because at HubSpot, every decision needs to be supported by data, and every month there’s a big meeting to show the results of those choices.
It’s a great way to do marketing, but it’s also very time consuming. With this first email, I sought to make HubSpot’s approach to marketing available to everyone in a simple and automated way.
The original design for this email was something I first conceived while at Performable. I wanted a short, daily summary that could be quickly scanned and understood. To do that, I leveraged three design patterns:
Emphasize the big picture.
Use color coding to tell the story quickly.
Create a strong visual heirarchy to communicate importance.
Here’s the most recent version:
The feedback on the email has so far been very positive. Our first release of the email even satisfied our dream scenario: one of our customers wrote us a glowing review, saying how the PowerPoint saved his skin when he had to rush to a meeting he was unprepared for.
We’ve kept the pressure on by releasing two other emails: the Daily Prospects Digest and the Weekly Progress Report (below). We approached both of these emails with the same vision that drove the monthly email, and they’ve turned out to be big hits with our customers.
What We’ve Learned
Know your metrics. We went into this with very clear goals, and we used those metrics to drive our design decisions very strictly. While this sounds limiting, it was actually very helpful.
Test before you send. There are a lot of quirks in email design, so it’s important to test for them as best as you can. Between the three emails, we easily looked at a couple thousand screenshots of our emails in different email clients throughout the entire design process.
Reuse what you’ve learned. To maintain the quality of future emails, we’ve created a basic framework and done as much as we can to set the principles for HubSpot emails. When you see an email notificaion, summary, etc. from HubSpot, you can expect to see a very similar interface and the same design patterns at work.
If you have any feedback about the emails (don’t worry, you won’t hurt our feelings :]), please share it in the comments below!
If you find the topic of email tantalizingly enjoyable, you might like to read the first half of this two-part series: Quirks in Email Design.
Isn’t Email Old News?
Email has been around for a while, so all the good tricks would have been found by now.
False.
There is still much hacking to be done in email, not just by providers, but also by consumers and third-party vendors. Here’s a quick list of things we’re doing to make email better at HubSpot:
Programmatically changing email content
Converting images to HTML (where appropriate)
Cleaner, more elegant preview text
Better environment detection (e.g. mobile vs. webmail)
A better email boilerplate
Let’s get right down to business and take a look at the code.
Programmatically Changing Content
I’m not going to dive in deeply on this one since I already wrote about this technique in November. However, I’ve made a small update to it that make it more reliable. Here’s the latest:
Converting Images to HTML
Sometimes, you just really really want to get around those pesky image blockers to entice people to see more. To do that—but mostly to see if it was possible—my coworker Keith Barrette wrote a little script that takes an image and converts it to email-safe HTML.
This isn’t for every case, and I definitely don’t recommend it for use on large images. However, this experiment would be really useful on small images, like logos, which render with higher fidelity than larger, curvy images. This lets us keep a subtle reminder of the HubSpot brand in the email, even when images are blocked (which happens 52% of the time according to this Campaign Monitor blog post).
It’s Keith’s code, so I’ll let him share it with the internet when he’s ready.
Elegant Preview Text
One thing that’s often overlooked is the preview text. Even Campaign Monitor (sorry guys) seems to overlook this in their own marketing emails. It’s not a huge deal, especially if you have a long email subject, but it can sometimes make a noticeable difference. Besides, sweating little things like that are what make your emails memorable and polished.
There are two main ways people will see your preview text:
1. As a desktop popup/notification (mostly desktop clients):
2. After the subject line (almost all clients):
Don’t get caught with “Hi Jane,” or a “View This Email in Your Browser” link as your preview text. Instead, you can simply insert a 1x1px image immediately after the body tag and assign it some alt text. The alt text will get picked up by email clients as the preview text, but it’ll still be properly hidden. In order to play nicely with all clients, your pixel should look like this:
If you’re looking for bonus points, you can use that same image as your tracking pixel! Just fill the source attribute with a link to your data collection endpoint (we’re doing this at HubSpot).
Environment Detection
Sometimes it’s useful to do different things based on the environment you’re working in. For instance, you’ll probably want to have a mobile version of your email when it’s being viewed on an iPhone, and this should be different from the printed version of your email, which should have it’s own set of styles.
It’s also important to note that these environmental detectors can be used to trigger tracking pixels, so you can record actions, environments, device types, etc. Huge hat tip to the innovators at Litmus for inspiring me to go down this path. Those guys are doing so much email voodoo that it’ll probably be years before anyone else catches up.
Forwarded message: your content will be wrapped in a <blockquote> tag. Printed message: do a @media query for a print style sheet. Mobile: use @media queries. You can even use these to figure out the device’s exact make and model. Non-Gmail: you’ll probably never need this, but you can use the <style> block since Gmail doesn’t support it. Microsoft: surprisingly, you can use conditional comments, much like you would in an HTML web page.
A Better Email Boilerplate
Much of the above has been rolled, in some fashion, into an improved email boilerplate here at HubSpot. It’s still pretty new, but I’m hoping we can use this as a baseline for future emails we send to customers. It’ll also be something we offer to customers who send email through HubSpot and use our in-house email templates.
I don’t yet feel comfortable about disclosing the code, but here’s a summary of my favorite boilerplate features:
Rock-solid wrapper. I’ve done 90% of the work necessary to make sure your email looks the same (and beautiful) across all email clients.
Fixes for the iPhone. This makes sure fonts, phone numbers, addresses, etc, are rendered nicely.
A “remove from mobile” CSS class. If there’s something you think will clutter the mobile version of your email, just assign class="hide" to it, and poof!
Drop-shadows and rounded corners. This will intelligently fall back to loading images when CSS 3 isn’t available.
Litmus-style tracking pixel (for internal use). We use this to track opens, forwards and prints. We also do our own click-tracking in-house.
Preview text (rolled into our tracking pixel).
Some features that I’m looking forward to adding eventually:
More specific fixes for the different email clients.
Better hover- and click-state support.
More CSS 3 effects and smarter fallbacks.
I’ve been diving pretty deeply into making amazing emails at HubSpot, and I plan to upload some screenshots next week of what those emails look like. I think they’re some of the best summary emails being sent by any SaaS company today (I’ve been keeping count). If you have any awesome ones, please share!
I had the chance to give a quick talk at HubSpot on the stuff I’ve been doing with email (like programmatically changing email content after it’s been sent). In order to do email justice, I’ve broken it into two parts. Part one is about how to properly design for email. Check back next week for part two: How We’re Hacking Email at HubSpot.
Problems with Email Design
There are lots of constantly changing variables.
Creating a beautiful, stable email is arguably more difficult than designing the equivalent web page. You have multiple types of desktop email clients which each have their own quirks and restrictions. There are also an ever-increasing number of web-based clients, and each can be viewed in any of the 7+ major web browsers. In total, you end up coding for over 65 different environments.
Your code is augmented or overridden.
There are multiple places along the way where your content can get parsed and mutated. Once you hit the send button, it’s out of your hands.
You’re only armed with HTML and CSS.
If you want to do something really clever or unique, start wracking your brain for ways to do it with CSS2. Even then, there are only a handful of things in CSS that are fully supported by all of the clients.
border
border-collapse
color
table-layout (no idea what this does)
most of the typography stuff
This means that even basic CSS properties that we took for granted (background, display, position, etc.) aren’t fully supported. When you’re designing an email, make sure to keep that in mind and know when to take a risk and when to play it safe.
How to Approach Email
You should approach email like a worthy advisary. Understand the playing field and do your best to level it.
Know your browser distribution.
Especially before you try to do something fancy. Some browsers are more restrictive than others, and it’d be a shame to invest a lot of time in a specific email technique only to find that a majority of your customers use clients that don’t support that feature.
At HubSpot, almost half of our customers use some version of Outlook, but a decent amount of them use Apple Mail and iOS. Because of that, we have a decent amount of room to do cool things with email.
Avoid inline important flags (!important).
Inline important flags have the highest level of authority in CSS. If you’re looking to override something in a CSS block later on, don’t use an inline important flag. In a general way, understanding the order in which CSS declarations are inherited is pretty useful knowledge to have.
Lastly, be mindful of file size limits.
Gmail and some mobile devices truncate messages that are too large. This usually isn’t a big deal, but make sure to test for it when you can. Emails that are particularly image-heavy are going to be very slow to load on a phone over a 3G (or less) network, and your customers might not be willing to do that.
Some Basic Solutions
Code like it’s 1998.
Or whenever the internet was invented. I think it was sometime before I was born.
Use tables, inline styles, and avoid fancy CSS tricks like floating elements.
Assume nothing.
Be painfully explicit about all of the CSS rules that you set or unset, and remember that you may need to do things to override the existing environment. For instance, <h3> tags are green in Hotmail by default, so you need to explicitly set a CSS rule on those elements in order to get the color you want.
Some Quirks About Tables
Tables are awesome for email, but there’s a reason we stopped using them for websites a long time ago: they’re rigid and suck. Here are a few techniques to make them suck less.
Style your <td> tags, not <tr> tags.
Generally, <tr> tags don’t have many useful CSS attributes, and they’re certainly not very good at handling margins, padding and borders. Save yourself some trouble and don’t bother setting any CSS rules on these elements.
While you’re at it, don’t worry about the <thead>, <tbody> and <tfoot> tags either.
Use divs for spacing.
Margin and padding work just fine on <td> tags, but it can get annoying to update your margin/padding styles when you have a row with 10 columns. Don’t fall prey to using the <tr> though! Instead, wrap all of your columns in a <div>.
Common Gotchas
Here are a few interesting things I’ve picked up since working in email.
Crashing Outlook with images.
I’m not exactly sure why, but Outlook requires images to have a protocol (http or https) in the “src” attribute. So if you do something like:
<img src="//www.example.com/image.jpg" />
Outlook will freak out, seize up and ultimately crash.
Hotmail and the color green.
Any <h2> tag and above will automatically be turned a Kermit-the-Frog-green if you don’t use an !important flag.
Outlook 2007+ use Microsoft Word.
Of all the weird things I’ve seen in email, this is the one thing that baffles me the most. Versions of Outlook prior to Outlook 2007 used Internet Explorer to render emails. This means that if you were designing an email in 2005 and it looked good in Internet Explorer, there was a very very good chance it’d look exactly the same in Outlook.
But some time before the launch of Outlook 2007, the team there decided to ditch the browser that their colleagues had built and use the half-baked rendering engine from Microsoft Word. They even wrote up a blog article explaining their decision to continue using it.
Check back next week for part two: How We’re Hacking Email at HubSpot. If you understand the basics of email and want to push the boundaries, I highly recommend reading the next part.
A research article published in 2006 stated that first-time entrepreneurs only have an 18% chance of success (it’s worth noting they didn’t define “success”). As entrepreneurship gains popularity, we see more companies popping up, which means we’ll see more failing companies. To avoid becoming one of those failed companies, I tried to think of some basic rules that might help identify a good company:
Find an advantage that big companies have, and make it available to everyone.
Build something that invests in itself.
Look for high-paying jobs that are largely rule-based and automate them.
It’s worth saying that these three techniques do not lend themselves well to people who want to build a company to solve a personal problem. Instead, by looking for opportunities that meet the above, you’ll find solutions to problems you may not be excited to solve. And from what I’ve been told, passion for what you do is a must for any entrepreneur.
Bring it to the Masses.
A favorite strategy of the late Steve Jobs, he sought to bring cutting edge technology to mass market. In an interview he did while at NeXT, Jobs talks about his vision of making the most powerful computers of the 1990s affordable and attractive to college students. Computers had been around for a while before Jobs started NeXT, but they were only used by big businesses and researchers. As Jobs put it:
“If we can take what we do best, which is to find really great technology and pull it down to a price point that’s affordable for people, if we can do the same thing for this type of computer [...] then I think we can make a real difference in the way the learning experience happens in the next 5 years.”
In many ways, the graphical user interface (GUI) that Jobs helped bring to Apple was paramount to its popularity. Macintosh users didn’t need to know DOS commands or work in a terminal to use a computer. Jobs made computing easy and affordable, thus making computers accessible to nearly everyone.
The Perpetual Motion Device.
If you’re a Marc Benioff fan, you might also be a fan of this tactic. In his book, Behind the Cloud, Marc Benioff talked about how useful it was to be building a sales tool (Salesforce) because the company was able to use it themselves.
This is one of the things that makes companies like Salesforce and HubSpot known for their sales and marketing, respectively. The money that you’re investing in technology, in theory, improves your product and empowers the function of your business that uses it. By doing this, you also eat your own cooking, which makes empathizing with your customers even easier.
Some products that I think are great candidates for this:
Sales and marketing tools: improve your ability to acquire customers
Support tools: deliver premium support at extremely low costs
QA tools: redundantly monitor the health of your own tools
Because this category pays dividends, it’s a good place for any company to invest in internally.
Displace a Human.
Years ago, in order to do search engine optimization correctly, you needed to hire an SEO guru (or worse, a firm) who would research your keywords, do detailed analysis and invest time into auditing your website. They would then spend several weeks harassing you about updating the pages of your website until everything was picture perfect.
Today, you can instead use RavenTools or SEOmoz to audit your website in a matter of hours. Their tools will automatically recommend keywords to you and maintain a detailed analysis that’s frequently updated, so you can spend your time insightfully harassing someone else to fix your website.
This kind of software carves out a portion of the industry’s “pie,” but only “eats” a portion of that slice. For instance, if SEO consulting was a $100 billion market and SEOmoz replaced half of it while only charging 10% of what people were previously paying, they’d have $5 billion dollars while simultaneously depriving consultants and firms of $45 billion. That money either disappears or is reallocated, and SEO professionals may or may not see any of it.
Because of this situation, companies that compete with automation products fight over an already small portion of the larger pie. If SEO consulting is a $100 billion industry, and you plan to automate half of it for 50% of the cost people traditionally paid, your market would be worth $25 billion, and $25 billion would disappear. Now, your competitor can’t simply take the other $25 billion that you’re not collecting, because customers are either going to choose your product or your competitor’s, not both.
Bottom line: if you’re looking to replace people with a product, you have to be the best.
Choosing the right startup idea is less important than choosing the right team, but it’s always good to have that edge. If you’re confident in your ability to lead an early stage startup, why not start thinking about what that startup will be?
Talk about innovative technologies, not antiquated ones.
Update the UIE website, for the sake of credibility.
The full message is included at the bottom, after Jared’s response. His answers are really good, and from what I could tell, not documented anywhere else. Jared was kind enough to allow me to post this here on my blog. Hopefully, other people find it enlightening.
On Nov. 29, 2011, Jared replies:
Hi Jonathan,
Thanks for answering my question. I didn’t think it was harsh at all. In fact, I agree with all of it. It’s all places where we could improve.
To speak to your points directly:
Citing our sources: This is a constant tension around here. We try to do it as often as we can, and we probably could do it a bit more. However, there are reasons you don’t see it as often as you’d probably like:
1) People talk to us because we *don’t* get specific in our sources. In many cases, we couldn’t talk about what we’ve learned in any more specificity without running into a huge set of NDA and IP battles.
2) We’ve learned that when we describe our research methods in more detail, people focus on that detail more than they focus on the findings. We don’t want people focusing on our research — we want them to take what we talk about and go investigate their *own* users using their *own* designs. Our goal is to start a dialog and create a vocabulary around design. We don’t claim to dictate good design practice; we’re just trying to get people talking about it.
3) A lot of our research is work-in-progress. We’re still collecting data and feeding it into our analyses. We are often reporting mid-analyses results to see what people resonate with and to find out what questions come up, so we can adjust our course. Talking about the specifics of how we’ve gotten there just complicates that conversation.
All of this drives us to be more general in our descriptions, do a lot of handwaving, and not cite the specifics as often as we probably should. That said, if you ever have a question on how we’ve gotten to a conclusion or what the research is, please ask. I try to answer as much as I can when this comes up.
Up-to-Date techniques and innovations: I hear you. Frankly, we’re not at the leading edge of this stuff and we’re up front about that. We see ourselves as more historians than of reviewers. We choose technologies and techniques that have a proven track record before we talk about them.
I get that you’re at the forefront of this stuff, ahead of where we’re at. Fortunately for us, our audience (which is mainly composed of insurance companies, hospitals, financial services firms, universities, and government) thinks things like Modernizr is leading edge stuff. Hell, they think using javascript is a new advance (the feds JUST got permission to use it in their public-facing web apps from the White House).
Part of our problem is we need people who can write and speak effectively to these technologies for our audience. A lot of the folks who are at the bleeding edge are smart, but not very good at communicating effectively. We vet our folks pretty well to meet our audience’s needs and I’m always scouting.
Things like OpenGL and Sass are very much on our radar. We’re waiting to see them get a bit more traction, have some great enterprise-level examples to show, and find the right people to talk about them. It’ll probably be a little while and I’m guessing it won’t be soon enough for what you’re looking for.
Cleaning up the UIE website: Man, I can’t tell you how much our web site is the bane of my existence. (Almost interesting fact: most of the core of UIE.com was written by Josh Porter 10+ years ago, when he worked here.) I talk about this with the staff frequently and I’m sure they are tired of hearing about me whining.
We’ve done better with our temporary sites recently. (Our most recent event site for the User Interface Conference was designed by Dave Shea and I think was worlds above where we’re at in other places.)
We run the company very lean. Most of the “profits” we make are rolled back into our research, because that’s where we think we get the most leverage on our investment. Because of that, we don’t have a ton of resources to put on our web site and everything takes a long time. None of us are designers or developers, so we have to do everything through contractors, which takes even longer.
That said, we’ve hired Dan Rubin to redesign our virtual seminar program site, which we’re gutting and rebuilding from the ground up. We are expecting that will then bleed into the other portions of the site where our blog, articles, and podcasts live. That’s expected to launch early Q2 of 2012.
We’re also hiring a web developer intern to help keep things maintained without using contractors. (If you know someone, we’ll be posting the ad in a few days. I think it’s a great opportunity for someone wanting to build up some experience and get paid to learn.)
Sorry if that’s a long answer to your response. Again, I appreciate hearing your thoughts on this and wanted to let you know where I was. It’s definitely things we think we can do better.
Jared
My original message to Jared, dated Nov. 28, 2011:
What UIE could do better:
You asked, so I’m going to answer :]
1. Cite your sources. I’m a front-end engineer, but I have a degree in Journalism, of all things. One of the things that is so painfully apparent in a high percentage of the articles on UIE is that you don’t cite specific research or exact people. It leads me to believe you’re either reanalyzing the same data set year-over-year or making it up completely.
2. If you’re going to write about new techniques or technical innovation, find highly technical people. I’ve seen a bunch of articles on how awesome Modernizr is, which is cool, but it came out in 2009. Talk about OpenGL, Dart, Coffeescript, Sass and LESS. Those are things interface engineers should be using today.
3. Clean up the UIE website. It’s hard for me to take the concept seriously when you’re not eating your own dogfood. I admit that the website is very “traversable,” but it’s a pretty terrible reading environment.
I apologize if this seems a bit harsh, but I think it’s somewhat deserved. UIE is capable of gaining a position of authority in an industry that is currently very fragmented and unfocused. By making UIE better, you’ll hopefully make the web a better place.
My biggest pet peeve is when when I’m talking to someone about a product, and they recommend a feature in the form of:
“It would be cool if…”
When I hear that, I usually just smile and let the person finish, then I tell him this:
There are two kinds of features in software: useful and non-existent.
Although it’s a nice side effect, “cool” features are not the kinds of things people really need. Above all else, a feature should be useful, otherwise it shouldn’t be built at all. If a feature in your product has lost it’s usefulness, it should be removed.
A UX designer named Jon Bolt discussed introducing new “features” as adding complexity, whereas most of us think of it as adding functionality. When we start piling on features, the product gets more and more complicated, so it’s important to make sure every addition is worth the added complexity.
Here are some traits of a useful feature:
Ties directly back to your customer’s bottom line
This one is my favorite. In many ways, return on investment (ROI) is the ultimate measure of usefulness. If you put $1 into a machine and get $2 back, it’s very clear that the machine is useful. This is a great metric for the usefulness of an entire product, but it’s also important to fine-tune this metric to individual features, at least for internal auditing.
Significantly decreases the time it takes to do a repetitive task
The two magic words here are “significantly” and “repetitive.” Additional features add complexity, so we need to get the most bang for our buck. Trying to decrease the time spent on every task is usually a design headache and leads to clutter.
Gives the answer to a pressing question
Very plainly: if you’re directly solving the customer’s problem, you’re providing value. Keep doing that.
Saves lives
This is a pretty obvious one, but I didn’t want to leave it out. If you’re in the business of saving human lives, every improvement toward that goal is useful. We can only hope that builders in that field of work take useful features even more seriously than the rest of us.
Let me know if you think I left any useful feature traits out!
I’m consistently fascinated when smart people parallelize previously serial systems. Asynchronous coding and branch-based code development, are neat, and physical examples like the Kiva Systems Warehouse are particularly cool.
So much productivity can be gained when systems work in parallel, that’s why I think it’s so important to unblock others.
Whenever I hear someone say, “I’m blocked…” I drop most of what I’m doing and divert all my energy to fixing that person’s problem and helping them become productive again. If a person on my team is held up by something I did or should be doing, there are seldom few things more important to me than getting them unblocked.
I once had a product manager, a young guy named Andy Pitre, who took unblocking very seriously. He reiterated to our team every day at standup that his main priority for the day was to unblock us, which included getting us out of long, administrative meetings, hassling other teams to finish or speed up their APIs, and other such nagging tasks that are necessary for operation and productivity but not directly tied to writing more code.
That system was pretty awesome. Every day, we’d tell Andy whose legs he had to break, and he’d hunt down the developers or managers and extract what we needed from them. It was insanely helpful to have someone who was good at rhetoric and office politics out campaigning while us engineers focused exclusively on product.
I probably wrote under 50 lines of code the other day at work, which is a pretty abismal coding day for me. However, that same day, I helped two developers get set up with proper development environments and launch their first apps for their teams. Those two devs now have everything they need to continue building out their application for the next few weeks and are far more capable of helping others in the future.
I understand that not every endeavor is going to be worth the time, but if I can unblock a good developer—and good developers aren’t blocked by much—, I’m certain that they’ll make back my lost productivity very quickly.
I love office pranks. And who these days deserves to be pranked more than the brogrammer? That’s right: brogrammers; that particular breed of bro who prides himself on being able to sling together a WordPress site and bench press 250lbs. Let’s hit him where it hurts.
