Product Stuff at Kapost

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 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. 


You Might Also Like