Do You Believe in Magic?


sparkles

 

I have been helping a few startups try to reach product-market-fit and have encountered a common theme: everyone is too tactical.  Discussions quickly digress into incremental benefits and features.  Attend any company’s product meeting and you’ll often hear debates about adding Feature X vs Feature Y based on criteria like development time and which one the customer would prefer.

Want to build a truly great customer experience? Stop talking about features – or even benefits – and start talking about creating an overall “magical experience.”

Think of it from your customer’s perspective.  Ask customers to describe their favorite products and they will almost never list out features.  Instead they describe an experience that is so amazing and so over-delivers on expectations that they can’t help but feel like something magical just happened.

Some examples:

Uber:  Need a ride somewhere? You used to have to wait for a cab and hassle with cash payments.  Now just push a button.  A personal driver *magically* appears and takes you wherever you want to go.  When you arrive you just get out.  The rest is all taken care of.

Sprig/Munchery:   Need dinner? Don’t think about cooking or calling for delivery. Choose a picture of a beautiful meal prepared by a professional chef.  Push a button and it *magically* appears at your house in 30 minutes.

Amazon Prime:  Need to buy something?  Don’t deal with the hassle of driving to a store and parking.  Tell this website what type of item you are looking for.  Then push a button and in 48 hours it *magically* appears on your doorstep.

At their core, almost all of the most used Internet services today are defined not by their features but by an experience so impossibly simple it just seems magical.

So what makes an experience magical?  Three key elements:

  1. It’s absurdly simple. Something as simple as “Push a button” or  “type in a word” or “wave a magic wand”.   Any work required by the user and the magic goes away.
  2. It’s doing a task that is normally hard. The harder the task feels to begin with, the more magical it will feel to make it simple.
  3. It’s helping solve an important need.  If the task you solve is not important you’ll get a nice “wow” but it just won’t have the same emotional appeal as fixing something that matters.

Before you create incremental features, take the time to flesh out the ideal “magical experience” for your customer.  What very difficult, important task are you going to make impossibly easy?  Ask your customer “If you could push a button or wave a wand, what would you like to have happen?” It’s a much easier way to figure out their most pressing problems and their ideal solution.   Then back into what exact product changes – feature additions, changes AND removals –  you need to make that happen.

Takeaway:

  • When building your roadmap, rather than focusing on features, focus on creating an experience your customer would describe as “magical” – then back out the minimum amount of features or changes to make it happen and remove everything else.

 

Technical Debt — when to deal with it?

One of the key themes In the upcoming presidential election is what should we do with the US fiscal debt. Some argue we should stop everything to pay it down right now; others think we should put our resources into improving the economy and then pay it down later when we have more resources (i.e. more GDP).

Technology companies face the same dilemma on a micro-level every day in terms of what is commonly called “technical debt”.  When developers write code for a product, they are inevitably writing in assumptions as to which things they will be developing more thoroughly and which they won’t.  For example, a developer initially coding an iPad app to track weight loss would likely put in extra code to record and share your weights on an iPad and not nearly as much code to record morning heart rates or sleep patterns or to record weight on another device like an Android device or a website.

The challenge is that your initial assumptions when you code often end up being completely wrong.   What you thought was definitely on the roadmap last week, might fall off completely after talking to more users, hearing about a competitor, etc… Likewise, the thing you thought was a tiny feature two weeks ago when you started building it now is considered the core of a huge new platform.

The result is Technical Debt — you end up with oodles of code that are being used for purposes for which it was not initially intended.  The code is sub-optimized so you end up taking much longer to build things, usually with more lines of code and more bugs.  The longer you wait, the more the TD will cost you valuable time and resources.  But fixing it means stopping new features, and spending time rebuilding functionality that already works.  It just  feels like you are wasting time that could be spent adding new functionality.

Every development product I have ever been involved with has at least some levels of technical debt.  So what do you do?  When do you pay it down and when do you ignore it?

One engineering philosophy wants to err on fixing all bad code.  As soon as you see any poorly written code, stop what you are doing and go in and find a more elegant solution.

At the other end are the people who don’t want to fix the code until it actually breaks and then go in and only clean the part that is broken.

I am somewhere in the middle.  While it is great to have super-elegant code everywhere you look, I think it ends up being a waste of time as you’ll be over-optimizing.  Sometimes, once the code works you never need to change it, so spending hours refactoring it to make it elegant decreases overall efficiency.  At the same time, waiting for the code to break and only fixing the part that needs fixing ends up penny-wise pound foolish.  You are spending all your time and money repeatedly repairing an old clunker when it would have been cheaper and faster to just get a new car.

So here’s my philosophy.  When considering technical debt, I think about 3 things and make my decision based on them.

1)   How will cleaning up the bad code affect the next few sprints in your roadmap?   Fixing something now that won’t really help make your next few sprints faster is probably not worth your time.  On the other hand, if fixing technical debt will speed up development of functionality you need to build soon, you may be able to get it in for free.

2)   What is the frequency of profanities —   How often are you cursing the poor code quality?  If the curse index is high, it probably will help both productivity and morale to fix it.  On the flipside If you don’t hear people complaining about it a lot, it probably is not a huge pain point.

3) How firm is your deadline?  Everyone has deadlines, but if your next deadline is an absolute MUST-make  (i.e. you are showing it to your largest customer’s CEO on date XX), you may want to just delay the technical debt until missing your deadline is not quite as costly.

So how do you handle technical debt?

First Impressions

At Shop It To Me, we are constantly experimenting.  It’s one of our core values.  In fact, as of this morning, we have 24 different A/B experiments running on different parts of our site.    Each week we probably add anywhere from 1-5 new experiments to our testing pool (and take out 1-5 old ones).  We experiment not only with small features but big ones too.  At any given time have 1-2 completely new products that we are testing with a subset of our users.

But unlike a lot of companies who announce any new feature or product, we don’t announce even our biggest products when we first put them into the wild.   Even though we have press asking for new things and we could get a great “usage spike”  we actually tell our PR team not to talk about them until the time is right.

The problem is, until you have nailed the product, a press “spike” is just a spike.

Now don’t get me wrong, I’m not a big fan of the “stealth company” technique — companies that promote that they are doing something amazing but won’t tell you what they are doing.  I think these companies actually set such high expectations it is really hard for the user to beat them.

But I am a fan of not announcing a new product until we are pretty sure it is a hit.  Why?  I am a big believer in the disproportionate power of first impressions.  Humans are hard-wired as a species to take a tiny bit of data and extrapolate big decisions/impressions from it.    It’s leftover from when our ancestors had to quickly decide if a creature is predator or prey, and it is still in almost all of our decision making.

We make significant long-term, big decisions based on only on a first impression all the time.  Have a terrible first date and there’s a pretty high chance you will give up before going on a second one (even though even your “soul mate” and you are likely going to have bad days together).  Try out a new restaurant and have a bad service experience and you likely won’t ever return — even if they later get great service reviews.   And in business, start off a presentation poorly and much of your audience likely stopped listening  (and will rate it poorly) even if remaining 80% is amazing.

Remember that before spending loads of money announcing your next product. If someone tries your product and just likes it (or thinks it is mediocre), you have likely given them the permanent impression that your product is just OK.  They won’t return.  On the other hand, get a user to have an “I LOVE THIS!” first impression, they often will still have positive impression years later.  We’ve seen this time and again —  our best users are the ones who found something they wanted to buy in their first emails.

So before we turn on the PR machine for a new release and send it to all of our users, we make sure that almost anyone who sees the product is going to have a great first impression — such a good impression that they want to keep using it (and hopefully tell their friends).   How?  We spend months usability testing the heck out of it —  constantly tweaking it with user-testers and thousands of random users and friends and family-members and even random people we recruit off the street (yes we’ve done that).  And we learn from them and make the changes that gets their reactions from “Meh” to “Like” to “Love” (a subject of a future post).

So while we may lose some “brand-awareness” and short term traffic from multiple product releases, we more than make up for it by having a product that for most people feels “pretty awesome” right from the start.

 

Focus: What is your product going to be awesome at?

One of the most important things to do when you are building a product of any size is to focus.   Pick the few things you are going to be amazing at and the many things you will not be.  It’s hard, but it’s the only way to succeed.

Try to be great at everything and you’ll end up with a mediocre product.  Focus on one thing to be great at and you have a chance to dominate your competition.  Why?  You can align your entire company (sales, marketing, product, dev) on just one goal and therefore do it so well nobody can compete.

Take Google Search.  Since their launch their focus has always been one thing:  Get you an answer to your question as fast as possible.  Their home page doesn’t have ads or news or anything but one big search field.  Most of the features they add have traditionally been about making that better.  Or take Walgreens. They don’t have the best selection or the lowest prices.  But they succeed because they are the most convenient with stores on pretty much every corner.  They’ll pay up to be on every street corner so that at the moment you need something you first come to them.

When we are thinking of building out a new product, I generally ask three questions: Where do we want to Win? Where are we just going to Play (and be just good enough)? And where are we purposely going to Lose (and let someone else win)?  A great product will have all three.

At Shop It To Me, we want to win on personalization — understanding you, the consumer, like nobody else  and then showing you the most personally relevant items on sale.  And almost everything we do reflects that.  We launched first in a category (clothing) where personalization is super-important.  We require all of our users to tell us all of their individual preferences before they can sign up.  We have invested in sophisticated technology to figure out which sizes a retailer has available each morning and which are sold out so that your email only has items in your size.

When it comes to personalization — we purposely do the hard stuff.  Our system knows which items you have seen before so you don’t get duplicates and even tries to guess items and sales you might like based on not only your behavior but the preferences of others like you. We send millions of emails every day and each one is different —  individually personalized for its recipient.  It’s the reason why my mom, my wife and my teenage cousin can each feel like the Shop It To Me emails they receive are “just for them”.

To keep this focus, we are willing to give up on winning other things: We don’t have a celebrity promoting us; our site is pleasing but there are many that are prettier; we don’t include fashion advice or content in our emails;  our item pictures are good but definitely not the best.

And for many things that are critical to most shopping sites,  we are willing to lose completely:  we don’t play SEM arbitrage and our SEO is terrible.  Why?  None of these matter for a personalized product.  In fact, they hurt it.  Instead of optimizing for a transaction, we want to build a long-standing relationship with our users — and that requires a different type of interaction and focus.

In fact, I believe it is our unending focus on a personalized shopping experience that lets us succeed and thrive in a crowded marketplace.    While some companies have made personalization a feature (and are trying to shortcut it by guessing based on what you clicked or optionally asking you) — we have made it our core which means when it comes to building a product “just for you”, we can beat them every time.

So my question for you product managers out there:  What do you want to be awesome at?

How we celebrate the little things

Running a startup is definitely an emotional roller-coaster ride.  You are going to have really good days (like when you are featured on The Today Show) and a bunch of down days as well.

Your product development will always be much slower than you want;  you’ll put your heart into product changes you think are great but the customer balks at (or even worse, doesn’t notice).   You’ll put in an experiment “destined to win” until it meets the real world where it promptly loses by a large margin.  And as you go through the meandering customer development process of  learning what exactly the customer wants, it will feel like your  company is going nowhere.   Add that all up and if you are only waiting for the end goal it will feel  like it will never come.

So how do you stay optimistic and keep moving forward?

At Shop It To Me, instead of only celebrating the final goal, we make an effort to celebrate the little things.   We release new functionality weekly, and with every weekly release comes a mini-celebration (“Beer-Thirty”) — reveling in what was accomplished that week, the hard work that was put in, and the fact the product is (almost always) better than the week before.  We celebrate that we put the experiments in and found out the results even if they weren’t the results we actually wanted.

And we’ve been experimenting with another way of celebrating too — the “mini-milestone”.   Each product team comes up with a set of small milestones that are achievable in about a month’s time.  The milestones are not guaranteed to happen, but likely if everyone works hard (   examples include a set of features or experiments included or a metric goal that shows we are making some progress.) Each time we achieve a milestone. the team is given a small allotment ($250 or $500) to spend on the company and celebrate that milestone — they get to pick how.    The celebrations are usually not that big —  examples include a fancy brunch for the company or a Nespresso machine  — but so far the result has been super positive.  The team gets recognized for the work they have done, the entire company sees that progress is being made towards reaching our bigger goals, and after each celebration the teams are more motivated than ever to be hosting the next one.