Thursday, May 11, 2017

An Easier Way to Decide

Originally posted on ForeverCar Blog:
You probably have far more important priorities than taking the time to research vehicle service protection plans. That’s where we come in. When we set out to create the latest innovation to our consumer shopping platform, we vowed to keep it simple.
If you are not shopping for vehicle service protection at, you are likely sitting across the desk from a loan officer at a bank or a finance manager at a dealership. There are a couple problems we've identified with this scenario:
It’s bad timing. You are typically involved in a larger, more complex loan transaction involving your vehicle. Taking the necessary time to research the offering is impractical and highly unlikely to happen in that moment. That’s why most people pass on vehicle protection at the bank or dealership.
Wrong amount of detail. There’s a lot to this. A service contract is full of important coverage details, financing requirements, and claim information. While that shiny one-page brochure at the loan desk may look nice ­— it’s likely there’s a lot of information you’re missing.
Based on our familiarity with millions of shopping experiences and thousands of contracts and claims, we created algorithmic intelligence that offers the most popular plan. From there, we put the buyer in the driver’s seat. 1Quote lets you explore as much (or as little) detail as you want. We even encourage you to download and review a sample contract before you purchase a plan.
Most importantly, 1Quote is about helping you make a more educated decision — in a fraction of the time.
There are dozens of considerations when choosing the right plan. Luckily, our market research has identified three variables that affect the pricing, buying and claims experience.
By answering these simple questions, 1Quote delivers the best plan for you – at a price, duration and coverage level that fits your needs. Take back the driver’s seat and unleash the power of 1Quote today.
With a ForeverCar Vehicle Service Plan, our team of Protectionators can help with everything from getting a tow truck and rental, to recommending and coordinating mechanic repair services and payment. You will rest easy knowing that if a breakdown should occur, you’re covered the whole way with ForeverCar.

Monday, January 25, 2016

Ember: Actions Up, Data Sideways

The rallying cry for Ember 2.0 has been “Data Down, Actions Up”. Ember's component based architecture sets a pattern where data is passed “down” to child components, while children “request” changes from their parents by triggering actions. This certainly has its advantages ... until it becomes unwieldy. My colleague @ForSpareParts and I have been deep in the trenches implementing an analytics and big data product in Ember for a number of months now.

He wrote a great article about an alternative to Data Down, Actions Up and proposes the alternative architecture we have landed on. Its a good read:

Monday, November 9, 2015

Debugging Minified Javascript

This is an error we got in the early morning hours from our staging environment:

c is null

There are lots of things to like about minifying Javascript except this of course. Removing proper variables annihilates context so completely.

Thursday, July 9, 2015

Your Inconsistent Design Makes Me Worry About Your Entire Product

This is from a product I use daily. Who wrote this code and thought they were done? Who approved these two button styles next to one another?

I have this vision of a developer choosing a library that made their development life easier. I picture this code going straight into production use without review. Next, I picture the designer who works there rolling their eyes, checking out, and heading to LinkedIn to see what other opportunities exist.

I'm being unfairly harsh, but it makes me wonder what other sloppiness is happening inside this product.

Friday, March 20, 2015

Applying user centric design to your business plan

Image by Lars Plougmann
I got asked by an investor recently how we at Digital H2O do design. I liked the conciseness of my response and thought it was a good example of how to tie user centric design into a business plan. Here goes:

Our design philosophy is best described as user centric design. Our goal is to only design and build features our current, or potential customers, find valuable and that substantially help our business continue to grow. We spend significant time listening to our customers’ needs throughout the sales process. We then form hypothesis what customers’ needs are and what they can accomplish in the application. While designing features we show mock-ups and prototypes to customers in order to get feedback and incrementally improve the design. After the product is built and released we continue to test our hypotheses about how customers will use features we have built. We utilize automated event tracking in the app to monitor user activity. We continually interview customers via formal interviews and check-ins, but also by taking the time to deeply understand what they are trying to accomplish during support calls and sales check-ins.

Tuesday, January 6, 2015

How to start a product redesign - a playbook

A few months back I was working on a large, ground-up redesign for a product I own. I had a little trouble getting started. I realized I needed a playbook to remind me of the basics. I am sharing my playbook for those who are having trouble and procrastinating getting started. Enjoy.

Before you start

  1. At the highest level, in one paragraph, what is a representative user's goal and the problem you are solving for them? 
    • If you can't answer this succinctly you have many, many features or you don't know your users well enough to continue. 
    • Slow down, answer #1 for each feature set before you go to #2.
  2. What's working for them now?
  3. What's not?

What you need to design for them

  • Verify you are building all the tools they need.
  • Show the process they will use to reach goal - give them a map or trail to follow.
  • Indication of progress toward the user's goal - "You are here"
  • Make sure you build in escape hatches because they find a better way.
    • Very few user's "flow" from point a to point b. You can force them into a wizard pattern, but its more likely you will bore them and/or lose them in your flow.
  • Build in tracking of user activity so you can verify users are reaching goals.
  • Build in an internal review process to periodically review how well the features you built are working. I always learn from usage metrics as much as talking to actual users.

Tuesday, July 15, 2014

The sum of my experience with product making

People make companies and products. Process helps support and grow good people, but fundamentally it's all about the people.

There is a whole lot more to it than that, but this is the first thing to know.

Tuesday, February 26, 2013

Advice for Developers and Designers Working Together

From my talk at the University of Chicago Booth School of Business:

Excellent advice on getting developers, designers and managers to work together. It's featured here in our [UrbanBound's] latest blog!

Friday, January 18, 2013

Customer Development for "Product You"

As a manager I've always found it hard to get honest feedback from employees and my management. In larger companies the feedback culture in management often boils down to: positive feedback leads to good reviews - which leads to expectations of paying higher bonus. Employees will give their managers good reviews even in anonymous 360 reviews.

The solution

LinkedIn's endorsement feature can a be used to get good feedback from people. It will tell you directly what you're bad, but it will tell you which are good at.

Here is how it works 


If you want to know if people generally think you are good at something
Look at how many people endorse you for that skill.  If you have lots of endorsements for other skills, but none for the the skill you are watching. Guess what? People are telling you you don't have it.

If you have a skill that you don't use often but you're wondering if you're any good at it
Make sure its on your profile. If you get a number of endorsements, people think you have that skill.
Maybe its time to hone that skill to perfection?

If you don't know if you have a skill, but want to test if you do
Go ahead and throw it up on your profile. People can always ignore it. If you get some endorsements there is some potential there. Maybe its time to start training.

I have almost 700 people in my network on LinkedIn. I'm getting a good sense of what people know me for. I also see where I need to do some personal marketing in order to let the world know I have a skill. The good news is that I am not surprised by what I'm being endorsed for.

Note: There are a few more steps you will want to do in order to fully run customer development on yourself. Customer development is not a term a coined. I discovered it via Steve Blank in his book The Four Steps to the Epiphany. I highly recommend you check it out.

Thursday, January 3, 2013

What Is A Product Showcase?

I couldn't find a simple description of a product showcase today so I wrote a quick one myself

The showcase is an important part of product development. In it the product development team shows newly developed features to the company's stakeholders before releasing them to customers. It promotes early feedback (before the cost of change is too high), facilitates communication between roles in organizations and ensures the correct product is being built.

Friday, October 5, 2012

An update to principled leadership

Photo credit: raphaelchekroun
One my most popular posts of all time is one I put up in 2009 about Principled Leadership. I still get traffic from this post and once got a very aggressive job solicitation based on the principals outlined in the post. Recently I came across a quote that nearly sums up the whole list in one sentence:

Smart leaders understand it’s not just enough to pursue, but pursuit must be intentional, focused, consistent, aggressive, and unyielding.

*I'm afraid I don't know exactly where this came from so, if you are the owner, please let me know so I can link back to you.

Friday, August 3, 2012

Shallow Copy in Ruby

I often wonder why some organizations only consider candidates who have computer science or computer engineering degrees. In the real world I have seen many great developers who have come from diverse backgrounds. However, I had an event recently that made me really happy I have a degree in computer engineering. It made me understand why the favoritism exists for computer science credentialed developers. I had an issue with an email template in Ruby on Rails that without a good mental model of compilers and, specifically, compiler optimization would likely have taken a long time to identify and fix. Here is what happened:

in a database somewhere...
UPDATE app_configs SET affiliate_template = 'Welcome to UrbanBound #[FirstName], '

def send_email_to_todays_movers

  Mover.each do |m| 
    @boiler_plate_email = AppConfig.find_by_config_name('affiliate_template').value
    [business logic goes here] 
    prep_mover m, @boiler_plate_email

def prep_mover
   [business logic goes here]
   @movers_name = Mover.find_by_id(
   send_welcome_email @movers_name, @boiler_plate_email

def send_welcome_email (first_name, boiler_plate)
   boiler_plate['#[FirstName]'] = first_name

*If this is good code architecture or not I'll leave for another post. We do most initial development of features as an MVP at UrbanBound. Its usually not worth optimizing code the first time we are testing a feature out. That being said I have a strict rule of using TDD and keeping 95% code coverage on models, helpers and controllers. Generally speaking, no business logic is allowed in the views.

The first time I ran this code (via rspec - I'm not this guy) the outgoing email message had the correct first name for the first mover. However, the others all had the same first name as mover #1. It didn't make sense to me at all. The boilerplate email template was changed in the send_welcome_email method but we refreshed it each time a mover was processed. Then I thought about my days doing C/C++ and how compilers work. Maybe the Ruby interpreter couldn't see three levels deep into the execution tree to see the boilerplate was updated. Perhaps it just did a shallow copy of the boilerplate after the first execution and was effectively sending a memory location of the boilerplate. Never updating it after the initial read from the database. After some experimentation I found that I was indeed correct. The compiler was performing an optimization that made the code faster, but didn't produce the intended action the programmer gave it. This is the trade off compiler builders always make.  Back in graduate school I could get my compiler to generate code that ran 2x-3x faster than the benchmark compilers, however after running millions of test data sets against it I noticed errors in 1 or 2 of them. This may be fine if I was playing in media, such as an mp3, but not good for computations that affected people's life and safety.

It turns out the solution is simple. Explicitly tell Ruby that you want a copy. Here is the code:

  Mover.each do |m| 
    @boiler_plate_email = AppConfig.find_by_config_name('affiliate_template').value.dup
    [business logic goes here]
    prep_mover m, @boiler_plate_email

I found another great description of the problem [here]