Yoav Shapira

Recent Posts

Should Your Startup Have Its Own App Store? Insights From HubSpot

By Yoav Shapira on July 14, 2011

The following is a guest post by Yoav Shapira one of the early team at HubSpot and VP Platform.  

Earlier this week, HubSpot unveiled its "App Marketplace," an area for customers and prospects to install "apps" much like Apple’s App Store or Salesforce.com’s AppExchange.

Why would we do this?  Doesn’t the world have enough App Stores already?  Does an app store really make sense in the world of business to business?   This article describes our early considerations on this topic, what we did, and why we did it.  We’re probably wrong on some of these things, and we’d love to hear your feedback in the comments.

We hope some of these thoughts help you structure your own analysis for your own business.

kingston-market-place-early 80s - power dressing, fur coats...


What’s the story behind the HubSpot App Marketplace?

Our App Marketplace started out as an area to test new features and portions of the product which were not ready for regular customer use.  We called it “Labs”.  We modeled the implementation on what Google has done (specifically, Gmail).  In Gmail, you can go to the “Labs” area in settings and enable a large number of additional features.  We implemented this “Labs In The Product” at HubSpot for the same reasons that Google did.  It’s a great way to get new features out to a self-selected list of users, measure results and iterate quickly. 

Customers were very positive about this approach.  It was clear which parts of the system were still new and in “beta”.  As our functionality evolved, we recognized that these cool new “Labs” features didn’t have to just come from us.  Third party developers could also build nifty new capabilities that would help HubSpot users.  Also, as it turns out, people are quite used to the notion of an “app store” (thanks Apple!), so we shifted our efforts into what is now the HubSpot App Marketplace.

Why not have another Beta approach, like sending some portion of our traffic or customers to Beta versions of the software?  

We like this approach.  We’ve been doing it for years, and we continue to do so.

What the App Marketplace brings to the table, besides the familiar metaphor for customers, is that it puts the customer in control.  They decide if and when to install an app, and can remove it at their leisure.  So it’s not quite a controlled A/B test, but it’s much more optimized for the customers themselves.  We like that.  We also like that instead of us choosing some random sample to test out a new feature, we can get data on which of our customers are interested in which kinds of capabilities.

But don’t you need many developers building stuff for a successful app store?

As it turns out, no, you don’t ;)  Especially while we were thinking of the app marketplace as a “Beta” channel, we planned to simply have our in-house developers create some apps.  In fact, this is how the first couple of marketplace apps evolved.

Our app marketplace model is a mixture of both quantity and quality.  It’s not extreme on either end.  We don’t want to be like Apple, controlling the entire experience very tightly, because that is painful for developers.  We also don’t plan to have millions of applications in there, as a B2B company, because our market is not quite big enough yet.  More on that shortly.

What we found is that of our existing hundreds of partners and VARs (Value-Added Resellers), at least a couple dozen companies have developers and are happy to work with us.  In fact, they see this as a channel to productize their custom integration work into something more profitable.  For these organizations, the marketplace provides an opportunity to build an ongoing revenue stream.

We’ve been working closely, and happily, with these early partners.  We’ve incorporated their feedback, and in turn, the ecosystem gets better for everyone involved.

We’d love to get more developers, and we have some ideas In this area, but we’re not shooting for millions.  We’ve been pleasantly surprised at the amount of interest in our marketplace from developers, and we’re working with them closely.  All the documentation and code samples are free / open-source, as is the discussion group, where everyone is welcome.

 Alright, but surely these developers want millions of customers?

Thankfully, that’s not the case.  Each of our partners does their own economic calculation, but it turns out for many of them, selling hundreds or thousands of customers, at up to a few thousand dollars per customer, is a very nice business.

It turns out the SaaS subscription model works nicely here as well.  We’re not selling $0.99 apps, nor $0.99 add-ons.  Apps like some CRM integration packages could easily cost tens of thousands of dollars, but end up costing a small portion of that amount in our marketplace, because the developer gets dozens of customers instead of one.

Isn’t this distracting from your core product work?

Yes, you should primarily focus on your product, and we do as well.  The app marketplace is supported by less than 5% of our development team, so it’s not a big distraction.  And it provides a channel that makes most of the rest of the team more efficient, at least when it comes to testing out Beta-type features or product ideas.


I get that.  But doesn’t the world have enough app stores?

There are three reasons we did this, all driven by customer feedback.

First, it turns out that marketing involves many different activities.  The number of tasks our customers have to do is very large, and we want to help them with the entire marketing process.  This would take us a very long time to build ourselves and like all companies, we too have limited resources.  The marketplace provides another way to help more of our customers, faster, whether we do the work or someone else does.

Second, customers are becoming more sophisticated over time, and they want to pick and choose among different modules or pieces of functionality.  It’s not a simple “one size fits all” when it comes to small business marketing.  We try to listen to our customers, so we’re giving them a choice.  But rather than have a very complex pricing matrix, we just used a metaphor they know and like, thanks to Apple et al.

Third, our customers are aware of other external applications that are available .  But they have told us they trust HubSpot more than a random web site they don’t know.  They already pay us, they already know us, and even though we don’t write or support most of the apps in our marketplace, they still prefer this to a random 3rd party.

Tammelan tori

Those were some of our considerations.  Stay tuned for another blog post coming soon, covering where we belong on the Apple / Google app store spectrum, how shipping a minimally-viable product totally worked (we haven’t built billing yet), and more…

Meanwhile, would to hear your thoughts on the pros and cons of trying to build a store/marketplace for your product.  Do you think we moved too early at HubSpot?  Should we simply have kept our platform development to exposing APIs and having "external" integrations -- instead of allowing applications to co-exist within our system?  All thoughts and comments appreciated.  We're learning as we go.

Continue Reading

How To AMP Your Engineers: Ideas For Energizing Your Best

By Yoav Shapira on February 2, 2011

The following is a guest post from Yoav Shapira.  Yoav is on the management team at HubSpot and runs our platform initiative.

At HubSpot, our small internet marketing software company, a major factor in our plans for world domination is our engineering team.  We want our developers, designers, product managers, and QA engineers to all be as empowered as possible, so they can produce their best work.

This is very common, naturally.  What company wouldn't want that?  But in my experience, most companies and management teams go about this empowerment in intuitive, but wrong, ways.

The result is the usual mix of complaints: slow product development, low quality, unproductive developers, and unhappy customers.

To me, the key to this puzzle comes from two researchers, Daniel Pink and Simon Sinek.  Their research spans psychology, organizational behavior, and behavioral economics, and it answers this question pretty well.  The main finding is that we need to stop using the old "carrots" like cash bonuses.  Instead we should use approaches that increase intrinsic motivations for these creative 21st-century tasks like software product development.

Daniel Pink speaks about AMP: Autonomy, Mastery, and Purpose.speaker amplifier

Autonomy, the dictionary tells us, can be understood as "The capacity to make an informed, uncoerced decision."  Mastery is about expert skills, in-depth understanding of technologies and ideas, and continued study and practice.  Purpose is about having a shared vision throughout the organization, at every level, of why we're here as a company, and why we're doing what we're doing, in service of something larger than ourselves.

Simon Sinek touches on many of the same topics.  He positions it as three concentric cirlces: the "What?" circle, the "How?" circle inside that, and the "Why?" circle inside the "How?".  If it sounds a bit strange, watch his TED conference presentation below.

In fact, you should probably watch both of these presentations now, or after you read this blog post.  You really should.  Both are short, both are great, and both apply to your company, I promise ;)



What I wanted to share today is not theoretical, but how we are trying to apply some of the above findings to our work at HubSpot.

(1) Product development teams run like small startups.  

Each team has a product manager, who can be a classically-trained product manager or an experienced developer.  More than half our teams today are led by an experienced engineer.  Each team has a small number, 2-4 typically, of additional engineers.

Each team also has a Customer In Residence (CIR), a member of our Customer Success team who speaks to customers all day long, every single day.  Finally, We also augment the team with specialist skills, like QA engineering or design, as needed for their specific projects.

Each team owns an area of the product.  And when I say they own it, I mean they really own it.  They not only decide what to do in that area, in what priority, and how to build it, but also what metrics are the important ones for that product area, how to track those, and what the goals should be for themselves for those metrics.  We think of the product managers as mini-CEOs of their own startup -- because they basically are.

This helps establish autonomy.  Real autonomy, where they can make their own decisions, drive their own metrics, experiment as they see fit, and be accountable for the consequences.

(2) Purpose: A sounding Board for advice and coordination.

Just like our company has a Board of Directors for advice and feedback and tracking progress, our management team serves as a Board for the different product teams.  We have a monthly Board meeting where each team presents its progress on the metrics they track, analysis thereof, and plans for the next month or two.  We have an open and candid discussion about what's going on, but the team decides what to do next.

small board cartoon resized 600

(Image from The Equity Kicker.)

Also like a company Board, specific Board members work closely with the teams, each one as an advisor, and each one helping only 1-2 selected teams so they are focused.  We help them look at the metrics, keep the big picture and company vision in mind, identify opportunities for coordination with other teams, and otherwise help answer any questions they might have.

This Board helps keep a consistent message on our purpose and vision: why are we here?  Why are we doing what we're doing?  What's the greater good?

We also do other recurring activities, like a periodic all-hands company meeting (followed by a party typically), an extensive internal wiki with transparent updates from everyone in the company, starting with the CEO and going to the newest employees, a weekly internal newsletter, and more, all intended to remind us of our purpose.

(3) Opportunities for mastery are everywhere.

As Daniel Pink tells us, it's important for creative professionals, including software engineers, to get better at our craft.  Besides the actual improvements to our work products, this also gives us a good warm feeling of continuous improvement, learning, and satisfaction.

There are a variety of ways to accomplish this goal, although really this is a life-long quest, not a binary "yes / no" badge.

Things like tuition reimbursement, for example, are pretty common and we love them.  But even there, your company can differentiate itself with a creative policy.  For example, ours is roughly "no paperwork, no manager's approval, you will get reimbursed, but you have to list your name, your course with link to materials if possible, and your grade, on our internal wiki visible to all employees."

A less common thing companies do, unfortunately, but one I think they should do more, is encourage employees to contribute to open-source projects.  These can be open-source projects we use at work, things we like personally, things we created at work and now made available to the world, or some other combination.

At HubSpot, we actually go a step further and look for open-source contributors as part of our recruiting process.  We find a high correlation between intellectual curiosity, a professional drive to be a better software engineer, and contribution to open-source projects.  It's not a requirement of course, but we really like it when we find those folks.

Sometimes you get an open-source project that on its face has nothing to do with your product: Git by a Bus, recently written and open-sourced by HubSpot engineer Edmund Jorgensen, is a good example.  It's a tool to analyze source code repositories for unique knowledge held in developers' brains ;)  But even that tool, which has nothing to do with our product, is a valuable engineering management utility.

Finally, we invented a little bit of our own custom opportunity for mastery, in the form of HubSpot Fellows.  This is a program anyone here can apply to.  It's jointly led by our CEO, Brian Halligan, and a Harvard Business School professor, Andrew McAfee, we recruited for this role.  There are classes roughly every week during the academic semesters, and they cover a diverse range of topics that the management team finds relevant to our business, and/or topics requested by students in the class.

All of these things together, combined with explicit encouragement from management to engage in these activities and improve oneself, lead to an enhanced sense of mastery over time in our engineers.  Or at least, so they tell us ;)

(4) Make it personal with a mentor

As readers of this blog likely know, many engineers can be shy or timid.  They often want the above autonomy, mastery, and purpose, but are unsure about how to ask for it, how to voice complaints, or even what they really want.

I found that having a more experienced mentor you can go to from day one with any question really helps with this.  We pair people up before they join the company, even, with a more experienced engineer.  It doesn't have to be an older engineer, just someone who's been here for a while and knows the system well.

We tell our new employees about autonomy, mastery, and purpose (informally usually), and encourage them to speak with their mentors / buddies any time they have a question on any topic.  I hope they specifically push their mentors on these topics in particular.

The mentorship is a stable, long-lasting relationship, hopefully.  It spans projects, team changes, and more.

(5) As with everything else, know that you're imperfect.

We know we're not going to get this all right in the near future.  There is plenty of room for improvement, and plenty of opportunities for us to make mistakes.  The good thing is we recognize that, and we try not to be arrogant.  We ask for feedback from everyone all the time, and (gasp!) we often listen and act on it.

Many of the programs above did not exist when we started the company.  They have evolved over time in response to feedback, both quantitative and qualitative, from employees primarily, but also from advisors and other "friends and family of HubSpot" people.

We'd love to have your feedback, so we can improve our programs even more.  What do you do to encourage autonomy, mastery, and purpose on your engineering team?

By the way, if you or someone you know is an awesome developer, you might want to check out what HubSpot is doing to win the battle for technology talent in Boston [there's a $10,000 bonus involved].

Continue Reading

Recommended For You

The best place to find me is on the HubSpot Network.

Lists by Topic

see all

Posts by Topic

see all


Let's Connect

And, you can find me on Google+, Twitter, and Linkedin.

Recent Posts

Chat with GrowthBot

It's a bot to help you with your marketing and grow. You can research your competitors, improve your SEO and a lot more. http:/GrowthBot.org