A dead simple way to improve your writing

Why does anyone think using the phrase “dead simple” is remotely acceptable?


DishwasherNow is the dead simple way to have a brand new dishwasher delivered to your door from iPhone.

Is “dead” an adjective for “simple”, which has morphed into a noun but has also ceased functioning in this world?

Or is this statement implying that the service is so easy to use that the walking dead can even order their dishwasher from the iPhone they are carrying in their lifeless hands?

Why can’t we just use “easy” or “simple”?

DishwasherNow is the easy way to have a brand new dishwasher delivered to your door.

See how much better that reads? You don’t have to be a rockstar engineer or ninja growth hacker to understand what this phrase means.

EDIT: I’m on the losing end of this battle (from Google Books Ngram Viewer):

Dead Simple usage in Google Ngram Viewer

A practiced method to solve hard problems

Here at Mediafly, we are faced with hard engineering, product, sales and marketing problems every day. Each of us takes a different approach to solving these problems. Some of us like to create pros/cons lists. Others dig deep into data and use that help answer every question. No one approach is the “right” approach for everyone.

I recently had a conversation with our Engineering Manager[1], and he described his approach to solving hard problems.

  • Take an attempt to solve the problem, but don’t stress about it if you can’t figure out the solution yet.
  • Review the key aspects of the problem right before you go to sleep. This involves working on the problem from multiple angles. Meaning, if you tried one solution and it doesn’t work, try another. If it did work but it’s ugly, just note the key parts of why it works and why it’s ugly. You need to get intimate with the problem and be really familiar with it from all angles.
  • Now, let the problem go. Sleep on it, take a shower, go for a run. Do something to take your mind off of it entirely.
  • When you least expect it, an insight will find you. When the solution does find you, immediately explain it to as many people as you can. Don’t worry about whether they are an expert in the subject domain. Just start explaining. The mere process of explaining acts as a forcing mechanism to refine the solution further. It also serves as a filter; if what you thought was initially a great idea turns out to not be, attempting to explain may allow you to filter out the seemingly-good idea much more quickly, and get back to solving the problem another way.

I’ve watched him apply this method of problem solving over the years, and it truly is a thing of beauty. He will often take 2, 3, 4 attempts at particularly thorny engineering problems. He will sometimes throw away the code he wrote for an attempt and go back to the drawing board. He will restart this process from scratch as necessary. But, regardless, he almost always comes up with a solution that solves the problem elegantly. And watching his success has led me to begin adopting this approach for problems of all sort that I face as well.

[1] Special thanks to @laimis for being the inspiration for this method and this post! And he credits A Technique for Producing Ideas as inspiration for this process.

Dear Enterprise Software Product Managers: Consider Scale


Discussions about design and UX for software these days so often focus on onboarding. Scott Belsky, founder of Behance, even suggests A good discipline to help you stay simple is to focus at least 50% of your effort on onboarding and the first-time-user-experience. Providing a great onboarding flow is the quickest way for your users to find value in your new feature. After all, the sooner a new user is able to find value, the more sticky it’ll be for them, and the less churn you’ll experience, right?

Makes sense, and it gives a great starting point for how to think about a new feature. For example, from Mediafly’s point of view:

  • A newly signed-up user will start with 0 content, 0 salespeople, 0 users. Envisioning that scenario is very straightforward.
  • A small business might be using SalesKit by Mediafly to manage 50 pieces of sales collateral among 20 salespeople, distributed to 500 prospects. There is some complexity with this level of information, but for most features you might design, it’s probably pretty straightforward.

Often, however, this is where the design of a feature stops.

When you’re working with enterprise organizations with large user counts, diverse business processes, very large data sets, or whatever key metrics you track, however, you need to consider the user experience when there is high volume of use in these key metrics.

Example 1.

From the beginning, we designed Mediafly’s content management system (CMS), Airship, to start as simply as possible. From day 1, users could drag in content from their laptop, with reasonable defaults, and immediately get value. As our customers adopted our CMS and scaled out their use across diverse business processes and groups, we continued to discover issues that we could never have foreseen at launch.

Recently, a large customer (a major CPG enterprise)began uploading merchandising layout diagrams, hierarchically organized by region, for each of their tens of thousands of their customers’ stores to our system. This dramatically increased two key metrics: their volume of content (tens of thousands of new documents) and frequency of updates (thousands of changes every week).

Automating the upload and management process on their end is a no-go, as there is no common backend system where these documents reside. And, asking people to update these layout diagrams with our Airship CMS would require 20-40 hours a week of navigating, clicking, and dragging/dropping.

To address this, we conceived of a new upload model in which an adminstrator of a one of their region’s merchandising layout diagrams could organize the new content hierarchically on their laptop, zip up the file, and upload it into our system. We would then interpret the results and update the content automatically in the correct location. This solution at once solves both the problem of content volume and update frequency. And it can be reused for other customers who encounter similar challenges.

We spend as much time solving user experience challenges of scale as we do thinking about how to build compelling new features whose adoption will begin at very low volumes.

Example 2.

We recently released the ability for our content administrators to create special links to view content, which has been a hit with our Media/Entertainment customers. The link can have a password, be tied to a user account, or be public. Creating a link is straightforward, and initial reception and usage of this feature started off as very positive.

But, after a few months, we began to hear feedback from content admins about some challenges they were feeling as their use cases for links expanded. The volume increased dramatically in some of these use cases. We now see that some admins have to create as many as 200 individual links for individual users in a single day, usually around television pilots or key screening seasons.

After diving deeper into some of these workflows, we created a process diagram to show what the typical process is to create a link. The content admin:

  • Switches to their email client and composes a new email
  • Pastes in a template that they use for their emails
  • Switches to Airship
  • Finds content in the hierarchy
  • Navigates to the Links tab
  • Taps Create Link
  • Configures the link
  • Saves the link
  • Clicks the option to copy the link to the clipboard
  • Switches back to their email client
  • Pastes the link in
  • Sends the email

Whoa, that’s a lot of steps. Imagine having to go through this process 200 times in one day! For some admins, it requires the entire day.

We have since simplified the process to create a large number of links, and continue to improve upon the feature to solve the problem of high volume even further.

How these experiences have changed us

As we design new features, we now include an extra question to answer: What will this look like at high volume? At the design phase, we strive to have a hypothesis on how we would address problems of scale, and to see what we can do to simplify the initial UX even further should scale arrive faster than we can roll out a redesign.

However, just like most things we do from a product and engineering perspective, we operate iteratively. We certainly won’t prematurely optimize for scale. But by simply adding this question to our checklist of considerations, we’ve opened up the ability to solve the seemingly inevitable high volume issues that will arise.

(This post was cross-posted from the Mediafly Blog.)

Announcing SalesKit Meeting Tracker

(Cross-post from Mediafly and LinkedIn)

Here at Mediafly, we work hard to make the lives of salespeople better. We talk to a lot of salespeople, and what we hear from reps over and over again is “I hate my CRM.” This feeling comes from many reasons:

  • While CRM is very valuable to sales management, salespeople find these systems add little to no value to their primary job as salespeople
  • After a long day or week of meetings, salespeople have to drag themselves into their CRM to record notes of what happened in each sales meeting they had—instead, they want to be working towards their next deal or spending time with their families
  • CRM systems in general are clunky, complex, and require a lot of clicks/taps to accomplish the most basic of tasks

What does SalesKit Meeting Tracker do?
Once SalesKit Meeting Tracker has been turned on for your company’s environment, tap on the “Meetings” button and start tracking your meeting.

Start Meeting

When you’re done, stop tracking, record the meeting’s details, and send them to Salesforce.com.


Complete Meeting

Your meeting’s details will appear within the Activity History for the account, contact, and opportunity you’ve chosen.

What’s coming next?
We have a rich roadmap for SalesKit Meeting Tracker, including integration to our other app platforms (web, Windows, Mac, Android) and to other CRM platforms (Microsoft Dynamics, SAP Cloud for Customer).

Navigating the Product Roadmap

Navigating the Product Roadmap

As is the case at many other startup/early growth phase companies, we at Mediafly haven’t hired a product manager. “Product management may be the one job that the organization would get along fine without”, and we’ve lived by that model for the past few years. Because of this, we operate lean and create our own best practices for the meaty parts of product management, most notably the product roadmap.

The product roadmap is necessary for any enterprise-focused SaaS company that is selling multi-year subscriptions to Global 2000 companies like we are. It’s used as a communication tool for:

  • Clients, both the ones signing the checks as well as the heaviest users/admins of your product. They want to understand (and influence) what is coming down the pipeline for your product
  • Product development team members, including designers, developers, QA, and infrastructure. They want to understand what they should be thinking about from a UI/UX/architecture perspective
  • Sales and marketing. They want to know what they can sell, how it should be marketed, and provide input from a client, competitive and market-driven standpoint

Defining the Roadmap

An Example of Mediafly’s Product Roadmap

It can be easy to let the roadmap balloon into a complex, time-sucking monster. The roadmap itself is housed in Google Sheets, and broken up by product category (for us, those are SalesKit, ProReview, Airship CMS, Interactives, Reporting, andInfrastructure/Security). We organize specific entries in the roadmap into five columns, with the following definitions:

  • Discovery: Ideas/features that are “baking.” We usually hear of these ideas from clients, prospects, users, or the market, and are looking to gather more information for these ideas before we move them to the next phase.
  • Evaluation: Once an idea has gathered sufficient input, it moves into the Evaluation phase. During this phase, we’re putting together benefits statements, wireframes, high-order engineering estimates, and public-facing selling documentation.
  • Plan: After we’ve committed to building an idea as a feature, we attach a delivery date (usually a quarter, sometimes a month), and move it to Plan. Here, we are working on detailed requirements, wireframes, and phasing. We are also conducting usability tests and starting to talk about the upcoming feature with our clients and prospects.
  • Build: Once the feature reaches our design and engineering teams, it is in Build.*
  • Release: Recently released features are moved here. At this point, we’re training our clients, updating documentation, and analyzing usage in preparation for improving our newly released feature.*

It’s All in the Details

Sample Mediafly Details Document

Some entries in the product roadmap will be hyperlinked to a Details Document, which is hosted in Google Docs alongside the roadmap itself. These documents will vary in structure, but often contain:

  1. Estimates
  2. Requirements
  3. Current and proposed approaches
  4. Discussion of tradeoffs and limitations
  5. Specific customer requests

Every 3-4 weeks, I will review the roadmap with our business leaders (currently, our CEO and EVP of Sales and Marketing). We focus on what’s changed since our last meeting and discuss new data that we’re seeing from clients, prospects, and the market. Then every 2 weeks, I will review the roadmap with the Product, Engineering and Customer Success teams. We focus on what’s coming up in the near future, and often will dive into the specific points to discuss better ways to solve specific problems.

Ad-hoc, I will be asked to present the roadmap to our customers. This is usually accompanied by a short presentation that explains what the roadmap is and how it works. Over the course of any week, I’ll spend about 1-2 hours reviewing and adjusting entries within the roadmap based on conversations, research, and incoming data.

We’ve managed to keep the product roadmap useful and relevant without too much overhead over the past few years by following this model. As we grow the entire Mediafly team through 2016 and beyond, this process will certainly evolve. I’m looking forward to that evolution, and will keep you up to date as it progresses.

If you’re involved in product management at your organization, please comment below with your best practices. I’d love to hear from you!

(Cross-posted on the Mfly Blog)

Turn off Multicast Name Resolution (LLMNR) to speed up Dentrix Treatment Planner

The Dentrix G6 installation went relatively smoothly for the Belmont office of Forever Dental. After a few days, support came in and installed eCentral so we can file electronic claims. That’s when the problems started. Specific Dentrix modules (notably, Treatment Planner and Chart) were running extremely slowly. Treatment Planner would take upwards of five minutes to open a patient chart. This made no sense: it’s a small (but growing!) second practice, and there is no reason Treatment Planner should require so much time.

Our setup is relatively simple:

  • Windows 7 running G6 Server
  • 5 Windows 7 workstations running G6 Clinical or G6 Frontoffice workstation
  • All 6 machines connected to a router and obtaining IP addresses with DHCP. Nothing fancy like static IPs, hosts files, etc.
  • LogMeIn Hamachi set up on all machines, so that we can Remote Desktop into those machines

After 2.5 hours with Dentrix, they stumbled upon a solution: disable link-local multicast name resolution (LLMNR). My theory is that Hamachi adds so many subnets as the network grows, and unless you have static IP addresses mapped to names in the hosts file, LLMNR requires each request to a name to timeout before finally identifying the proper name-to-IP-address mapping.

Yes, it worked, but even as I wrote the above, it felt wrong. So if someone out there knows what is really going on, please leave a comment!

Why does Amazon.com allow crazy prices?

I was looking for a bike helmet for our 2-year old son, and pulled up “kids’ bike helmets” on Amazon.

Amazon Kids Bike Helmets

Look at that first entry closely. Specifically, look at the upper bound on the price range.

Ridiculous upper bound on kids bike helmet on Amazon.com

Why would Amazon allow an upper bound price like that on such a simple item? Is it purely oversight, or is there some crazy psychological result that results in more sales when items are merchandised this way? Does anyone know?

A Python script to generate a random, fuzzy image

I am creating a speedtest tool that is more reflective of reality for our customers.

To do this, I need to create a series of unique images that are approximately 1.5-2MB in size, as that is the average size of our HDS fragments.

Here is the Python script to generate a single image:

x = 300
y = 200

import png
import numpy
l = []
for i in range(0, y):
    l.append(random.randint(0,255,x * 3).tolist())

(png.from_array(l, "RGB")).save('image.png')

After this, tweak and repeat.

Here is what an individual image looks like:
Random fuzzy image created with Python

Strategy is Culture

Mediafly in the Inc 5000

(Cross-posted from the Mediafly Blog)

When I used to envision how small companies create a great strategy, I would often imagine a single or multiple leaders sitting down and writing out something to the effect of “here are the three things that we’ll do to win.” The picture in my mind is complete with a boardroom or conference room, men and women wearing business suits, and hours of PowerPoint presentations at the ready. My experiences at a management consulting firm reinforced this: oftentimes, decisions started as hypotheses by the most senior leaders, and were then justified back to them by consultants who gathered and made sense of data.

After growing Mediafly by 657% over the past three years (and that’s not even including 2014 or 2015 numbers), I’ve come to shift my mental picture of how strategy is built at small companies. The big conference room is replaced by a small one, often with people on the other end of GoToMeeting; suits are replaced by jeans; PowerPoint is replaced by conversation with a few bits of data thrown in; and the confidence of “here are the three things that we’ll do to win” is replace by “here are what we think might be good to try, based on a little bit of data, a lot of intuition, and a willingness to adjust as we learn.”

But the biggest surprise in my mental picture comes from how we develop strategy. Our strategy is highly influenced and often derived by our incredibly empowering culture and system of ad-hoc conversations.

What makes our culture empowering?

At Mediafly, engineering, customer success, marketing, sales, and even interns have open, candid conversations with the executive team every day, passing along ideas and feedback in both directions. Customers can pick up the phone or write an email to anyone on the team, and expect to get help to solve issues. If team members find something they don’t like about any system, they are empowered to proactively fix it. Many team members work across divisional lines (engineering and marketing; sales and product; marketing and customer success), which empowers those team members to fix and grow even more.

What are ad-hoc conversations at Mediafly?

As a result of the culture, our team members find themselves in ad-hoc conversations about all parts of the business every day. Conversations will form at each others’ desks, over lunch or drinks, on our messaging systems (GChat, HipChat), and of course by email. These all serve to align how each of us thinks about our company’s place in the world. All of this coalesces and informs our company’s strategy.

A couple of great examples of what I mean:

Example 1:

Our strategy focuses on “content mobility”. Previously, this meant mobile (and primarily iOS) apps. However, several inputs came together to help us broaden and redefine this this past year:

  • Sales: We had several sales meetings in which it became clear that many companies simply won’t ever buy iPads for their sales staff
  • Product: After analyzing our usage data, we realized that the primary platform for using Mediafly is through our Web Viewer on a desktop browser (not a mobile device and not one of our apps)
  • Customer Success: A few conversations with existing customers crystalized that a desktop app would go a really long way to embracing Mediafly
  • Market: Windows Surface and touchscreen Windows 8 hybrid tablets are starting to gain traction

These inputs came in through our empowered team members thinking about their areas, via conversations at each others’ desks and at meals.

Assimilating these inputs was easy, when there were so many of them pointing in the same direction. As a result, we’ve begun to work on a desktop application and plan to release it within the next several months (stay tuned!).

Example 2:

We originally developed our Interactives Platform back in Q2 2012. At the time, we assumed Mediafly would build a consulting arm that caters to creating Interactives via consulting services to our enterprise customers, while our core team focuses on enterprise software licensing. We operated under this approach for almost a year, netting a reasonable amount of consulting work.

However, again, several inputs from our empowered team members, gathered via many conversations, helped reshape how we think about this:

  • Engineering and Product: Every time Engineering was pulled into an Interactive engagement during this time period, we had to delay work on the product side for a custom piece of work. However, the product side is where the bulk of our “enterprise value” would eventually come from.
  • Team: Getting sucked into consulting engagements of this form was extremely hard, and team members were working way longer than normal. This was largely because we weren’t used to the multiple back-and-forth design rounds required for consulting to overlap with product work, and time was tight.
  • Industry: we started to meet some great agencies and software development firms, and believed they could be incredible partners.

We made the decision in 2013 to terminate all new Interactives development for our customers (with a few exceptions). The result has been amazing: better products, better focus, happier customers, and partners who are doing amazing work.

As we continue to serve more customers with our phenomenal products and services, we will strive to:

  • Ensure team members continue to feel empowered to bring up ideas and issues,
  • Keep lowering friction for ad-hoc conversations to take place, and
  • Drive company strategy based on the output of our culture, as much as it is based on other external factors