Tag: product management

Product Stuff at Kapost

Posted on

As Kapost grows, I really aspire for us to continually get better and better at what we do.  I ran the product group by myself for so long that i’m really excited to have more kickass folks on the team now (Anthony, Niraj, Eric, Jace).  With this extra firepower, we are able to do some really cool things and we’ve done some recently.  

First, customer development.  We’re taking this to another level. We’re talking to customers more and more. We need to. As we get more customers, it’s harder to know if your roadmap is what they want.  Also, our product is getting more complex so the feedback has more breadth.  We’re off to a great start in 2014.  We had a Kapost conference in SF a few weeks ago and Anthony and I flew out there to talk to over 20 customers.  We talked about new features coming out and our upcoming redesign.  We got some great feedback. 

In fact, it worked out so well that we even had one of our customers write an article on Inc.com about how much she loved talking to us.  You know you’re doing something right when a customer starts thanking you for listening. 

Inc Mag article about Kapost

Second, we’re finally putting goals and metrics on product releases.  I’ve been thinking about this for a long time, but we’re actually doing it now.  Here’s the deal: when you’re planning a feature or new product, we (the PM’s) attach what success means for that product 8 weeks after release.  For one feature it means usage by 50% of customers 8 weeks after release.  For another, we had 10 customers asking for it, so we considered it a success if 7 of them using it regularly 8 weeks after release.  There’s lots of talk about customer development, prototyping, MVP, and agile methods, but much less about the followup that happens once a product is released. 

Our engineering team is evaluated by shipping code, but we’re evaluating our product team by whether or not they are hitting the success metric.   This has resulted in some interesting behavior in the product team such as: 

  • when a product is released they are much more inclined to explain it to the sales and customer success team so customers will know about the feature and use it
  • if a customer asked for a feature, they then make sure that the feature is adopted before moving on and if it’s not adopted, figure out why and fix it. 

After a product release, a feature should be adopted and hitting its goals.  If it’s not it’s either because the requirements were bad or the implementation is bad.  Either way, tracking the adoption is necessary.  This rigor is new to Kapost and already is paying dividends.  I have another post coming soon about why Mixpanel and Totango are great for tracking.

As Kapost grows (we’re now over 50 people), the teams get bigger and more sophisticated.  Lots of founders dread the growth because they no longer can have their hands on everything.  For me, i’m loving the growth of the company, the team, and our ability to do more. 

 

Tesla and Continuous Deployment

Posted on

I’m thinking about getting a new car. Mostly because i never drive my car, it frequently needs maintenance, and it just sits in my garage depreciating. So, i’d like to have a less expensive, more reliable car depreciating. 

Of course, the car i want is the Tesla.  It has everything a guy could want.  But it’s too expensive and the Tesla SUV (the Tesla X) isn’t available yet.  So, back to the drawing board.  I’ll keep you posted as to what i get around to. 

In the meantime, i thought i’d write a little about why I think Tesla is so great.  One key characteristic is how they release their cars. Most car manufacturers do a waterfall-style release schedule, meaning they do one step of the manufacturing process after another in a linear way:

  1. First, design the car and call it a model name (usually after a year)
  2. Second, produce the car in a factory
  3. Finally, release the car to the public
  4. Then, start the process over again with a different model. 

Most software companies (Kapost included) do it a different way, called “continuous deployment” where you release your product and then continuously update it every day, week and month.  This way you can take customer feedback and immediately make change and improvements for all customers. 

Telsa is doing this too. Their Model S sedan downloads firmware updates on a regular basis.  These software changes go much further than simply changing user interface elements in the dashboard (which is a monster 11 inch touch screen).  Instead, Tesla will modify major elements of the car from the suspension to its acceleration and handling characteristics.  When they found out that people were lowering the height of the car too much on highways resulting in fires from drivers running into debris, they made a quick firmware update not allowing the car to be lowered as much.  

What’s even cooler about doing this continuous release cycle is that Tesla has broken automobiles traditional release schedule.  Rather than waiting a year to roll out a new Model S, they have been continuously improving the product every quarter on the assembly line.  There are no model years to differentiate a Model S in 2012 from one in 2014.  

That’s just one of the reasons they’ll disrupting the industry.  I love it.