Good Product Manager, Bad Product Manager

November 8th, 2011 Posted in Entrepreneurship, Product Management
No Comments

Every once in s awhile I find articles about my current role at AppFog to see how I align. The gist is quite applicable, but this has to be transformed to be more applicable to a scrappy startup as opposed to a large corporation for which this was written.

 

Good Product Manager

Bad Product Manager

By Ben Horowitz and David Weiden

Note: this document focuses specifically on product management in the context of a “divlet” [small division] in AOL.  Related key assumptions are that there is a corresponding “business owner” in each of the brands, and that the “products” are generally online services intended for individuals.

A Good Product Manager plays critical role in a successful product.  A successful product is the highest impact contribution that anyone can make in the PD organization.  In fact, the number one criteria for selecting a Vice President is the candidate’s track record (or lack thereof) of successful products that become profitable businesses for their company.

Being a good product manager is so hard that most product managers at most companies fail to be good — and instead are bad.  Because product management is a highly leveraged position, a bad product manager leads to many other bad consequences, generally including the wrong product being built, which generally has a significant impact on revenue, morale, and reputation — of both the product manager and their company.

There are a number of straightforward principles that product managers can follow which will dramatically increase their chance of success.  Surprisingly, only very few product managers follow these principles.  Part of the problem is that these principles often are not articulated clearly, which this document attempts to address.

A final note is that product management is a demanding and high profile job.  Individuals should make sure they’re up to the challenge.

Summary points:

  • CEO of the product
  • Balance all important factors
  • Clear, written communication with product development
  • Clear goals and advantages
  • Focus on the sales force and customers
  • Other key skills
  • Really good product manager

CEO of the product

  • A good product manager acts like and is viewed as CEO of the product. CEOs drive vision and are ultimately responsible for their company’s success or failure.  The same is true with a good product manager in relation to their product.  Good product managers have a realistic vision of what success of their product means and they ensure that this vision becomes reality – whatever it takes.  Good product managers are viewed by the entire product team as the leader of the product.
  • Bad product managers think of themselves as marketing resources. Bad product managers define their role narrowly as a marketing resource: someone who writes data sheets, arranges press releases, gets customer feedback, etc.  Bad product managers get all of their time sucked up by the various organizations they work with, they take product team minutes, they are gophers for engineering.
  • Bad product managers have lots of excuses: not enough funding, the engineering manager is an idiot, Microsoft has 10 times as many engineers working on it, I’m overworked, I don’t get enough direction.  Once bad product managers fail, they point out that they predicted they would fail.  Barksdale doesn’t make these kinds of excuses and neither should the CEO of a product.

Good product managers balance all important factors

  • Good PMs take all important factors into consideration. As CEO of the product, the product manager must understand and balance a wide variety of factors that affect product strategy and execution.
    • The primary factors to balance include:
      • Company goals & capabilities. Good product managers understand (or seek guidance on) overall company goals and set product strategy in that context.  Good product managers also understand the capabilities and limitations of their overall company.  For example, a good product manager knows if their company wants to maximize per deal revenues through a high-end direct salesforce to a few hundred customers OR if the company wants to maximize customers with an easy-to-use product for hundreds of thousands of customers through a diverse reseller channel.  A good product manager also knows  approximately how much and what kind of marketing resources the company will spend on these products.  Good product managers don’t always know the answer to these questions, but they know enough to ask when they don’t.
      • Customer demand
        • Good product managers listen to customers but they probe deeper into the underlying problems to get at the compelling value proposition for the customer.  If you had a noisy car you might ask for a louder stereo, but you would probably be a lot happier with a quieter car. A good product manager gets at that difference.  Good product managers also know what customers can & will pay for (sometimes that’s slightly different than what they want).
        • Good product managers do quantitative research.
        • Good product managers are certain that if they build a certain product, customers will buy it.  Good product managers understand that if they screw this up, they might as well pack it in so they go the extra mile to make sure they get this right.
      • Competition. Good product managers understand the architectural and business capabilities of the competition and know where the competitors can go easily and can’t go at all.  Good product managers know they must be better or different or they’re dead.  Note “different” can mean things other than product differences, like integration or distribution..
    • Know what you know and what you don’t know. A good product manager is acutely aware of what they know and why they know it, as well as what they don’t know.  A good product manager understands the difference between opinions, hunches, and objective facts.  A good product manager knows that their job is to fill in these gaps in knowledge, not to defend or obfuscate them.  A good product manager doesn’t ruin their credibility by over-stating their knowledge.  Note: Tim Howes contributed the word “obfuscate,” so don’t blame marketing for that.
    • Think ahead and monitor your assumptions.
      • Note all these factors need to be considered both now and over the lifetime of the product.  That is usually 1 – 2 years from now.
      • Good product managers also know what their important assumptions are and they monitor them from time to time to make sure they still hold.  For example, if a server product’s success assumed dominant client marketshare, the product plan should be re-evaluated as soon that assumption is threatened.
    • Good product managers will actively confirm their understanding with their managers and others on their team.
  • Bad product managers miss the big picture or miss small but important factors. Bad product managers build a good product for a market their company isn’t in.  Bad product managers build a product that’s too complex for their company to sell.  Bad product managers build a product that will take too long to pay off.  Bad product managers ask customers leading questions and get biased answers. Bad product managers go on their instinct and “confirm” it with two unusual customers.  Bad product managers react only to the moves of their competitors and forget to develop their own product’s identity, letting it be just a hodge podge of what the competition is not doing.  Bad product managers aren’t savvy or confident enough to distinguish between interest and commitment to buy.  Bad product managers blindly listen to the loudest customers, and define a product that addresses yesterday’s needs of a handful of companies.  Bad product managers compare future products to today’s competition, or cite advantages customers don’t care about.  Bad product managers try to defend their lack of knowledge rather than gain the knowledge.  Bad product managers have blinders on and don’t notice when things change and notice only when their product fails.

Clear, written communication with product development

  • Good product managers clearly define product requirements — in writing
    • One of the most important – if not the most important – job for a product manager is to define clearly and in as much detail as is necessary what the product should do, how fast it should be, etc.  Good product managers don’t forget to specify critical information.  Good product managers err on the side of clarity and are willing to explain the obvious to make sure it’s understood.  Good product managers also specify the whole product, including release criteria, platforms, etc., not only the new features.  Good product managers also sense and tackle hard issues – in writing – early in the development process.
    • Note a good product definition does not come down from a product manager in an ivory tower, but is based on research, information and a logical, transparent thought process that the entire team buys into.
      • Good product managers know that engineers are scientists by nature and value data much more than opinion.  Also, engineering and other parts of PD (QA, Doc, etc.) should be involved in that process.
      • Good product managers define a clear product vision and target that empowers engineering to fill in the details that are difficult to specify or anticipate.  As part of this, good product managers also explain why engineering should build a particular product a particular way.  A good product manager will not ask for a two ton collection of certain parts that will look a certain way and hope it comes out as a Porsche.
      • A good test of a product manager is for someone outside the product team to ask 5 different people in engineering, QA, and doc what their product is supposed to do and why and get the same answer.
      • Good product managers are respected by their engineering teams.  Engineering teams involve good product managers in difficult decisions.
    • Good product managers gather information from engineering informally and verbally, but good product managers give direction in writing to engineering..  Written communication to engineering is superior because it is more consistent across an entire product team, it is more lasting, it raises accountability.
    • Good product managers attend product team meetings regularly and make sure they’re around when engineering is making tradeoffs.
  • Good product managers think their Product Requirements Document (PRD) is a big deal. The PRD is the single most important document the product manager maintains and in most cases should be the definitive source of direction from marketing to engineering (see Writing a Good PRD).
    • Good product managers keep PRDs up-to-date daily or weekly at a minimum.  Good product managers view the entire PRD process as a living ongoing process, because it is (engineering has new questions, market conditions change, etc.).  If anything changes in the PRD, a good product manager communicates the change clearly to the entire product team.
    • Good product managers don’t rest until they are sure that the product vision is consistent across product management, engineering, QA, tech pubs, and support and is reflected in the PRD.  They don’t rest, because they know that no great product ever emerged from a broad set of conflicting visions.
  • Bad product managers cut corners on communication with engineering or misunderstand their role. Bad product managers specify the how not the what.  They want light and ask for a candle when their engineers could have built a light bulb.  Bad product managers have a bad feeling about an aspect of the product but leave it murky.  Bad product managers worry about specifying every feature in detail thinking they know more about how to solve a problem or how the product should behave or be architected.  Bad product managers put off hard decisions until the end of the product cycle.  Bad product managers write a PRD and assume engineering understands it.  Bad product managers don’t have time to update their PRD.  Bad product managers update the PRD and don’t tell anyone, or don’t tell enough people, or don’t explain why.  Bad PMs change engineering priorities based on the latest customer feedback or latest hot sales situation without going through the defined process.  Bad PMs ignore engineering requests or calls.

Clear goals and advantages

  • Good product managers have clear goals. Good product managers are absolutely committed to success.  Good product managers define success as achieving explicit goals.  Goals that are important are written down.  Good product managers have written goals for their product and for their own personal objectives.
  • Good product managers know the advantages of their product cold. Good product managers know how their product will be better / different than the competition.  This comprises a key part of the overall product vision from day one and is reflected in most things the product manager does.  Good product managers have these advantages written down and are consistent.
  • Bad product managers. Bad product managers have mushy goals and mushy product advantages.  Bad product managers hesitate when asked for the advantages of their product.  Bad product managers have inconsistent product positioning and advantages change from time to time.

Focus on the sales force and customers

  • Good product managers are loved by the salesforce. A good product manager will be known personally or by reputation by at least half the salesforce.  Good product managers know that salespeople have a choice of products to sell and, at a higher level, companies to work for, and selling a particular product manager’s product is optional.  Good product managers know that if the sales force doesn’t like their product, they will fail.  Good product managers know that to win over the sales force they have to be some combination of:
    • Focused on making them money — good product managers focus on and understand that salespeople are under a lot of pressure to make their quota, this quarter, and that’s about it.  Good product managers understand most salespeople care about things in that context and not much else, so they put things in that context without making the salesreps make a lot of intellectual leaps.  “Bell Atlantic paid $3m for directory because of abc feature” not “abc allows referential integrity to be maintained across entries.”
    • Knowledgeable of what actually happens in the field — nothing turns off a salesperson more than a product manager who rambles on about their product features and seems to have no idea of the salesperson’s actual situation.  Good product managers know if the salesperson understands what the product does or not (and if not they start with easy to understand basics), if customers do (if not they explain more why a customer would care than what the product does), etc.  Good product managers speak from experience.  “When I helped Bob close this deal…”
    • Around –  they’ve been out in the field, been to sales training, been to SE training, been to pitches, etc.
    • A good presenter
    • Responsive
    • Fun
  • Good product managers know and understand customers. Good product managers know a handful of current and potential customers personally.  Good product managers understand the exact dynamics of real customer situations.  Good product managers leverage this knowledge with engineering, other customers, the salesforce, press and analysts, etc.
  • Bad PMs don’t have time for the salesforce or customers. Bad product managers focus on their product and competitors and aren’t sure what’s going on in the field.  Bad product managers delegate working with sales.  Salespeople have either never heard of or dislike bad product managers.  Bad product managers are boring presenters.  Bad product managers talk about how future products will be great, but the current products are weak.  Bad product managers don’t care about individual customers.

Key skills

  • Marketing & communication
    • Product management requires an understanding of and proficiency in though not deep expertise of a wide array of marketing functions.  For example, good product managers should be able to work effectively with PR and press and analysts, understand how to execute a product launch, develop collateral, staff a tradeshow, train the salesforce, etc.  (See Working with Press and Analysts.)
    • A core rule of good marketing is to have clearly articulated advantages that are consistent across materials (ideally from the PRD to customers to sales, etc.).  Related to this is the importance of creating leveragable collateral, FAQs, presentations, white papers.  In particular, a product manager should make sure a core set of updated collateral exists (annotated presentation, written positioning, primary silver bullets).  If your primary competitor is abc and the most recent competitive positioning on abs is nine months old and refers to the last release of their product, this is indicative of a bad product manager.  Also, good product managers take competition into account in developing their messages, but are not a slave to what the competition does.
  • Time management and sense of what’s important
    • Good product managers focus their time in two areas: 1) tasks that are critical to their product success (e.g., export approval, mandatory licensing arrangements); 2) tasks that have a high impact on their business (closing big deals, updating their PRD, etc.).  Good product managers also leverage their time by completing FAQs, having a standard annotated presentation, doing good training, etc.
    • Bad product managers put out fires all day.  Bad product managers complain that they spend all day answering questions for the sales force and are swamped yet don’t create FAQs or other leveragable collateral.
  • Discipline
    • A lot of product management is ad hoc.  Good product managers respect a base level of discipline and organization in their work.
      • Good product managers keep their project up-to-date in Signposts.
      • Good product managers send their status reports in on time every week, because they are disciplined.  Bad product managers forget to send in their status reports on time, because they don’t value discipline.
      • Good product managers don’t over-promise.  Good product managers keep developers doing product development. They don’t offer engineering resources for things that can and should be handled by sales or marketing.

Really good product manager

  • Really good product managers demonstrate group product manager skills and capabilities while they are product managers.  (See Good Group Product Manager / Dead Group Product Manager.)  These skills include:
    • Be paranoid.  Really paranoid.
    • Work well with executives.
    • Leverage the entire organization.
    • Use whatever intensity is required to close critical issues.

 

 

Read More

52 Shots and Startups (#52SS)

November 3rd, 2011 Posted in 52 Shots and Startups, Entrepreneurship
No Comments

Over the next 52 weeks I will have a shot with someone from the startup community once a week. I will meet entrepreneurs, VCs, angels, advisors, etc from the tech community starting with Portland. Some I may already know, but most will be new faces. Shots will include alcohol shots, but in most cases this will be shots of espresso.

I like learning about people. I like startups and I am heavily involved in one. I also enjoy coffee and an occasional drink. This blog is the fusion of these interests.

Read More

Writing a successful apology

September 16th, 2011 Posted in Entrepreneurship, Product Management
No Comments

One formula I found to work well for writing a successful apology is to write three statements (apology, problem, solution) with the common thread of openness and accountability.

As a scrappy startup focusing on your core proposition you will cause some pain to your customers all while they still love the product. We’ve made a few of these mistakes, some big (leaving a security hole and getting hacked), some small (sending an annoying email to everyone). We don’t try to deny or hide any of it. In fact, the fundamental principle that runs through our veins is openness and accountability.

In cases where you owe your customers an apology, here is a formula that has worked for us.

(1) I’m sorry for…

First, you must confess that you screwed up. In the process you must take accountability and you must be open about the problem. This is critical; when you apologize you must identify what actually went wrong. It is critical because it is also a big opportunity to screw it up if you don’t do it right. For example, if by accident you send an annoying email to a customer (we did this once), you should say “We apologize for sending an annoying email”, the worst thing you could do would be to write “I’m sorry you felt annoyed by our email.”

(2) This is what went wrong…

Explain what went wrong. Again, there is a right way and a wrong way. This is where you can get your customers trust back. If you explain the issue to them in detail, they will feel respected that you confined in them and they will support your decisions. If you use this as an excuse you will not gain the customers trust as it will be clear that you are not taking accountability for your actions.

(3) This is what we are doing to fix this…

Lastly, you must make things right. At this point, you have better fixed the issue or have a clear plan of action. If you do not, this should be your number one priority. If you fixed the issue immediately, thats great, but don’t wait to have a fix ready before sending the apology. If you don’t have a fix ready, make a damn clear plan on how you will fix this. The plan is actually irrelevant, what you are actually doing here is making yourself accountable by telling your customers to make you accountable. You must deliver on your promises or you will lose your customers trust.

This formula works. What makes this work, isn’t the three pieces of data, but it is the common thread that runs through them: openness and accountability.

Read More

How to Fix Microsoft

June 27th, 2011 Posted in Entrepreneurship, Product Management
6 Comments »

Microsoft is broken! I assume you agree with me, but if not, leave a comment or email me. Instead of talking about how it is broken, instead I’d like to look at ways that I would fix it. Based on my observations while working at Microsoft and at a startup (PHP Fog), I am making a number of recommendations Microsoft could implement. Starting from the bottom, the product team.

I am not an executive so I don’t know how to fix Microsoft from the top. I was never in any of the board room meetings or executive meetings so my guess is as good as yours. However, I was a Program Manager at Microsoft for 5.5 years working on components in Windows Server, Windows Client, the .NET Framework, and most recently Windows Azure AppFabric. The PM is one of three key roles working on product development at Microsoft, along with developers (who write code), and testers (who write code to test the developers code). Here is the list of things I would change, you will notice a few reoccurring themes.

1. Fire 90% of the Program Managers

Developers write code, testers verify. The Program Managers do everything else. The reality is that most of it is just intellectual masturbation; it rarely leads to direct contribution to the product. They are delegators and when they don’t have work to do, they create needless work for others. They seriously can spend 80%+ of their time in meetings and dragging others into them too.

2. Release weekly, not monthly or annually

Most products work on several year release cycles, and a lucky few work on several month release cycles. Whether the product is released on a longer schedule or not, the product teams should be releasing new functionality, even in small increments, every single week. Every release should be made visible to the fullest extent. Let people use it, play with it, break it, and provide feedback.

The benefits of this are endless. This will boost moral as there will be continuous gratification. The need for long term planning (“guessing”) will be alleviated and replaced with real customer feedback. Time will be saved from nasty planning and review meetings.

3. Get rid of NDAs

Saying anything publicly about plans is frowned upon at Microsoft. Keeping your mouth shut is justified by the fear of making promises to customers which can’t be delivered. This leads to an overall fear about saying anything about the product at all. It also makes it incredibly difficult to have a meaningful conversation with customers about product plans and getting their feedback on the product.

4. Fire all of the “Evangelists”.

There are a number of people at Microsoft that get the awesome job title like “technical evangelist”. These people get to present at conferences, they blog a ton, they do video demos, interviews, etc. They have it made. But they are not a part of the product team. The problem is that they are a layer between the customers and the product team. The product team built the product and they should get the glory of “evangelizing” it. But more importantly, the product team needs to have a dialog with customers and use these communication channels to hear what customers are saying directly. This is the perfect opportunity for the PMs. This is what they should be doing.

5. Say no to architects, specs, reviews, or approvals

I can’t even begin to explain how much time is spent by the product teams writing specifications, reviewing them, updating them, getting approvals from architects, peers, managers, etc. This phase of the development lifecycle takes up some %25-%50 of the time spent by the team. There are so many things wrong with this process: (1) customers are not involved in providing feedback, (2) the work is justified as a necessity for communication, yet they rarely get read after implementation starts (3) they are outdated the day the developer starts implementing them, (4) Time spent on writing specs is time not being spent on other far more important things.

6. More open community

The Program Managers, despite being “the voice of the customer”, actually get very little opportunities to talk to real customers. It’s shocking. Support is provided by some people in India, blogs are written sparsely, only the marketing department has access to the Twitter and Facebook page accounts for a given product, and there are only a few rare occasions where customers can get in touch with the product team. The product team should have control of the social media, they should be encouraged to write blogs, use the MSDN forums to the fullest extent, be on point to provide support, etc.  People at Microsoft will say “but anyone can go and do this”, the reality is that there are barriers to entry which just make it inconvenient.

7. Lower the bar for testing

The testers are often identified as the “quality gates”, the people that validate that the product does what it is supposed to do and that it does it fast and that it does it well. The problem is that the quality bar is so high that so much time is spent on ensuring that the product works the way it was “planned”; however, this also increases the time it takes to get the product into customers’ hands. The real testers are not the testers that work at Microsoft, the real testers are the customers. Once the customers validate that the product does what they wanted it to do, then the testers can start banging on the product to make it work well and make it work fast.

8. Fire the release managers

When you have a complicated schedule with weeks of pre-planning, planning, implementation, integration, stabilization, etc. you quickly need to hire a special type of program managers, who are called “release managers” at Microsoft. They are responsible for the schedule, pretty much like a Project Manager elsewhere. If some of the earlier recommendations are implemented, like a more frequent release schedule, lower testing bar, no review process, the need for the release manager will also be diminished (though not necessarily completely eliminated).

9. Refocus the PM role

Now I’ve fired 90% of the PMs, I’ve fired the release managers, architects and evangelists. This creates a gap which is prime for the PM. The Program Manager shouldn’t just “speak the voice of the customer”, instead, they should be fostering a relationship between the customer and the product. They should be providing support, blogging, presenting at conferences, tweeting, talking to customers with whatever channel available. They manage the team to make sure they ship small functional bits often and getting them into customers hands for testing.

Conclusion

There are two themes: go lean, and listen to your customers.

Based on these recommendations many people would be on the chopping block. In fact, some of the best people I worked with would be fired based on this criteria. I’m no exception. In retrospect, had I been my own manager at Microsoft I would have seriously considered firing myself.

 

Read More

Required reading for entrepreneurs

June 8th, 2011 Posted in Entrepreneurship, Product Management
No Comments

Here is a collection of some of the books that I think entrepreneurs (anyone starting a new software project) must read. Whenever I work on side-projects with friends (tech and non-tech) I tell them they should read these books. I’m likely to continue to update this list.

Pitching Hacks

This book comes as a recommendation in order to understand traction. Establishing traction, regardless of the form, should be the highest priority for starting a company. Without traction, a company is just a few signed pieces of paper and wasted time in developing a product. Once you think about how to show traction for your business, you will quickly realize your priorities and that much of what you that was needed (developers, an office, etc) is completely unnecessary.

 

The Entrepreneur’s Guide to Customer Development for Tech Startups

The fact that this is called a “guide” is spot-on. This book is like cliff-notes to The Four Steps to an Epiphany, which establishes the rigorous customer development methodology. This really does read like a step-by-step guide for building the minimum viable product.

 

ReWork

This is written from the founders of 37signals.com. I highly recommend this book for all software development teams, not just entrepreneurs. While the other two books help you understand your business and get it off the ground, soon you will need to get into a rhythm of execution. This will help you understand how execute building a product (priorities, choosing what to build and not build, deciding when to hire, working hours, etc).

Read More

Your opinions don’t matter!

May 17th, 2011 Posted in Entrepreneurship, Product Management
No Comments

If you are responsible for defining the product of your company/org your opinions (and thus ideas) don’t matter, customer dialog does.

As a product manager your job, among other things, is to define your product, that is, what the development team is supposed to build in order to satisfy the needs of the customer. This role can be disguised in many titles: Program Manager, Product Manager, CEO, etc. This has been my career for six years now both at Microsoft as a Program Manager and at PHP Fog as a Product Manager. In one case, Microsoft, there was very limited customer dialog (and damn it was hard to change that), and in the second, PHP Fog, I have a very rich dialog with customers. This had a number of downstream effects on their respective organizations and success. I want to share some of those observations in those two cases.

Microsoft: Limited customer interaction

  1. To be successful you must have strong opinions. You must be the first to state the consensus conclusion during debates.
  2. Product success criteria isn’t defined by product/market fit, it is defined by the most senior manager’s opinions/ideas (which are loosely correlated to product/market fit).
  3. Product success/failure is not correlated to individual product success/failure.
  4. You must persuade others to invest in ideas based on your arguments, opinions, ideas and research (not customer evidence).
  5. The perceived leaders are those that voice their opinion first and loudest (quite literally).
  6. Define fictional “scenarios” and “customer profiles” with fictional companies/names to highlight requirements.
  7. You hear people say “In my opinion”, or “I think” and “customers want” (that last one is usually invented)

PHP Fog: Rich customer dialog

  1. To be successful you must have strong customer evidence (sprinkled with some opinions)
  2. Product success is based on market goals which we can measure
  3. If I am successful as a PM I am making a very strong contribution to the success of  PHP Fog.
  4. My team asks me what to build, and I merely rephrase our customers to make it actionable
  5. The leaders are those that stimulate a productive environment and build relationships (team, partners, customers, investors, etc)
  6. Product priorities and requirements are backed by countless pieces of customer feedback
  7. Usually start sentences with “Customer [xyz] needs…”

Caveat: I am just highlighting the contrast, though at Microsoft some of those elements can vary in severity depending on the product.

As a product manager, if you want to build a successful product, start by throwing out your opinions. The magic is in being able to stimulate meaningful conversation with customers and making this actionable to the development team.

Read More

Design Your Business for Acquisition, Not IPO

April 27th, 2011 Posted in Entrepreneurship
No Comments

If you are thinking about defining the exit strategy for your company focus on getting acquired, not an IPO from the very start and design your business correspondingly.

I recently read “Strategic Entrepreneurism: Shattering the Start-Up Entrepreneurial Myths” by Jon Fisher, and wanted to share my take-aways.

Your business goal shouldn’t be to go for an IPO, but you should aim for an acquisition as your target exit strategy. Acquisitions get you the most amount of return in the shortest amount of time. An IPO on the other hand gets you greater return, but it takes much longer, and the risk is also much higher. This doesn’t mean you should aim for an IPO and  settle for an acquisition, it actually means you should aim for an acquisition because it will impact how you run the company.

Partner up with carefully selected customers. Find customers for your product who are also customers of your potential acquirer or are customer your potential acquirer would also want as a customer.

In most cases  your target customer should be an enterprise (or large company) rather than individuals. You get more return from one single large customer than many small customers given the same amount customer acquisition cost/time. Also, a large customer has the added benefit that you get to ride their brand recognition. Once you have one large customer it is much easier to acquire more large and small customers, while the reverse is not true.

Partner with your customer to define the product/service together. Any book written from a Silicon Valley vet post dot-com bubble will tell you the same thing. Don’t build a business by blowing through money first, rather, focus on building the product for a specific problem for a specific customer. This is the same message I’ve heard every modern startup chant. It is also the same that is formalized by the Customer Development process in Steven Gary Blonk’s ”The Four Steps to the Epiphany” (or the short-hand version). If that’s what you are looking for, go to the bible of the process, and don’t seek it in “Strategic Entrepreneurism”

Minimize dependency on VC funding. This is rather obvious as getting external funding means that your shares are diluted, the VC’s get the preferred stocks, and you lose control of the company.  This is important because VCs want to aim for an IPO and make decisions to grow-fast, but slow-and-consistent growth is more optimal for acquisition.

Focus on consistent growth of your business. Trying to build your business quickly, that is, front-loading product/service development heavily while having negative cash-flow is high risk because the customers may not come (or come fast enough) and therefore leads to a rapid demise. Instead, make sure that your expansion is consistent and driven by reinvestment of profits. The former strategy is typically associated with trying to go for an IPO as your target, while the latter is more targeted for an acquisition. Potential acquirers obviously want a company that has consistent growth of customers and not hemorrhaging cash.

Hire veterans from potential acquirers. This obviously makes it far more obvious to the acquirer that the company will easily be able to integrate into their business post-acquisition.

If you are thinking about exit strategies and you have some basic knowledge of startups I would just recommend reading chapters 4 and 6, “Strategically Designing Your Company for Success” and “Design A Company to be Acquired.” Much of everything else is intuitive or heavily covered in other books/blogs/etc.

Read More

Scaling Up, Out, and Around

March 16th, 2011 Posted in Cloud, Entrepreneurship
3 Comments »

The most common question we get at PHP Fog is “is this like a VPS?” Many PHP developers have worked with shared and dedicated hosting wonder what a “cloud-based” (fully managed) stack like PHP Fog can provide. We provide unprecedented scalability, but what does that mean?

Scalability in this context is the ability for your application to increase capacity to serve web pages by easily adding more servers (scaling out), or increasing the power of each server (scaling up).

Over the past few weeks I have been working at PHP Fog as a Product Manager. PHP Fog is a new type of hosting provider for PHP applications developers to build applications the good old-fashioned way but with easy scaling, reliability, speed, and easy deployment/management compared to traditional shared/dedicated hosting. As a Product Manager, I am the conduit between the product team (i.e. the developers), and the customers; in that context I get to talk to a lot of customers. Since most PHP developers build applications hosted on shared or dedicated (“traditional”) hosting, I frequently explain the differences between traditional and cloud hosting. Many questions can be answered by this PHP Fog Technology overview page. Most customers understand reliability, easy deployment, and speed; scalability leaves them hanging. So lets look at some scenarios where scalability plays a role.

  1. Site shut-down due to surge of traffic: You have a WordPress blog hosted on a popular shared hosting provider like HostGator, BlueHost, DreamHost or RackSpace. You have an article on their you post to a popular service like Slashdot, Digg, Mashable, or Hacker News, and it actually picks up traction. You get a surge of traffic to the site, and your site gets shut down immediately. Shared hosting fail! Your site will be shut down either because you used up your bandwidth, or because your website was impacting the performance of the other websites hosted on the service.
  2. Consistent growth leads to performance degradation and forces re-design: The first scenario happens, but it’s rare enough that few plan for it. The more common scenario is that you build some kind of small website and host it on a dedicated server. The website slowly gains popularity and it starts impacting the load time. Now you have to do a ton of work to figure out where the bottlenecks are, how to alleviate them, and quite possibly re-implement some core pieces to make it scale with the consistent growth.
  3. Paying for underutilized servers: You build a SaaS application for business customers. Looking at the usage pattern you will see that between 9AM and 5PM you get thousands of hits but virtually no usage after 5PM and before 9AM the next day. In that case you have to pay for the dedicated servers to run the applications 24/7 even though most of the time they sit idly.

In these first two scenario serving websites was hindered because some limited resources were depleted… which ones?Is it the web server CPU/memory? Usually no. Typically code is fast enough that it isn’t the first bottleneck. Avoiding some obvious poor implementations will help, then there are loads of ways for optimizing the code even further.

  1. Is it bandwidth (I/O) to your web server? Yup! Web servers are limited in the number of concurrent connections they can maintain (tubes aren’t big enough). This is typically the first resource that is depleted as a single page load requires many request/responses and each one does a little bit of processing.
  2. Is it database size? Rarely. Unless you are storing large data (e.g. images, GIS) in a database, chances are you won’t be running out of space on the database. For large data where complex queries are not required typically blob storage like Amazon’s S3 are a better option as opposed to relational databases like MySQL.
  3. Is it bandwidth to your DB? Probably not! The number of requests between your app server and your database is a fraction of the number of requests the client makes to your web server. Furthermore, databases are typically hosted in the same data center with high throughput and low latency between the web server and the database.
  4. Is it the CPU/RAM/IO on the DB? Yup. With larger data sets, more complex queries, needless queries, or sharing a database, it is forced to do a lot of query execution. This means that a single request can take a longer time to process.

This is just an introduction to the concept of bottlenecks and how to alleviate those bottlenecks. Before you figure out how to scale your application, first you need to make sure that it is written to be efficient end-to-end. There are many things you can do to make a website faster. Like with any problem, first you’ll have to diagnose, then you’ll have to solve the problem. To diagnose the problem you can use tools like YSlow, Jiffy, and WebGrind. These will only help you identify where the bottlenecks are; you’ll have to identify the root cause and fix it yourself. The article “Fast PHP – effective optimisation and bottleneck detection” is a great start for helping you fix those bottlenecks. Just as a hint, some common solutions include, caching, fixing slow code, optimizing DB queries and DB design, not using shared resources, client-side optimization (e.g. javascript), and optimizing intermediate code. PHP Fog does it all of this except making changes to your code.

Once you have done this, you can increase the performance, and therefore total capacity quite significantly. Caching alone can improve application performance 50+ percent. But once you do all these things, you will still need to handle more users. This is where scalability comes into play.
We can now assume that we’ve optimized the PHP application and the corresponding MySQL database to the best of our knowledge. And it still isn’t enough. There are two options for scaling (making more resources available) for your web server.

Scaling Up/Out

First option is to scale up your application server. This means you increase the overall power of the server (CPU, memory, etc). This will provide more of the resources we were talking about before. While easy, this unfortunately isn’t a good strategy for scaling. The server is still bound by its hardware (or virtual hardware), so there is still a clear limit when you just increase the power of a single server. Furthermore, as explained before, the first bottleneck is typically the bandwidth (I/O) not the CPU or memory, so this helps some, but it’s only adding resources but in the wrong area.

When scaling up does not work any more, the only other option is scaling out. You almost always have to do this yourself. This option is not provided by any VPS or most other hosting providers. It means adding more servers to spread the traffic across numerous servers. As mentioned before the first bottleneck is typically the bandwidth (I/O) on the web server. This a mechanism to spread the load, which is done by a “load balancer”, a special kind of server which intelligently forwards requests to one of your web servers.

I’ve been focusing on scaling up and out; however, scaling down for business is equally important. People want to pay only for what they use. If you need to use 5 servers for a couple hours a day it would be great only to pay for those five servers for those couple hours only. Traditional hosting forces you to pay for the servers on a monthly basis, regardless of how much it is used.

Regardless of the type of host you are using, there are a few things you will need to do to scale out: (1) get a new server from the host provider, (2) setup and configure the server software, (3) setup your application on the server, (4) setup the load balancer to distribute the traffic.

Scaling on traditional hosting

Scaling an application on traditional hosting is very difficult. All four of the steps for scaling out are done manually each time you want to add a new application. This isn’t trivial. There is even more pain involved with managing this over time. Every time you have to deploy a new version of your application, or add more servers there is going to be a lot of time spent on making sure everything is configured and setup properly.

Scaling on cloud hosting

With “cloud-hosting”, like PHP Fog, all of those steps are completely removed from the pictured and handled by the PHP Fog infrastructure. In PHP Fog if you want to scale out from 1 to 5 servers, PHP Fog will automatically do those steps 1-4 explained above in just 30 seconds. From our management console you only have to move the scale-slider from 1 to 5 and hit the “Confirm” button. When we say “easy scaling” that’s exactly what we mean. Scaling down is equally easy. Deploying a new version is also easy, you just push a new version via git push and your code automatically gets distributed to all the servers in just 30 seconds.

Read More

Today’s Startup Lessons

January 25th, 2011 Posted in Entrepreneurship
No Comments

Today I had the opportunity to meet with two people who have been entrepreneurs. One was with my manager at Microsoft, Justin Smith, and the other was Nikhil George of MobiSante (also a former officemate at MS). I asked both of them for advice, just as I have been with every other person I’ve been meeting who’s had experience as an entrepreneur. Since I met with Justin and Nikhil today, I’d like to share some of the wisdom those guys shared with me.

I’m summarizing only a few key points which are immediately relevant; some will be more relevant in later stages of the company. In the process of these meetings I also observed the alignment with Pitching Hacks and The 4 Steps to the Epiphany. If you haven’t read those, I highly recommend both.

  1. Move from Details to People: As a technical founder you can really get deep into the details of the business. In running a business it is equally (if not more) important to consider the people and your relationships with them and their interests.
  2. Cultivate advisors: You will need help and that help can come from advisors. Find people with expertise in areas relevant to your business. For example, if you are building a caffeinated peanut butter get and advisor who knows the peanut butter industry, or someone who is in the supply chain, etc.
  3. Cash flow is king: Cash flow (in flow in particular) gives life to your company. You need incoming cash flow either from customers or from investors to build the value for customers. This reminds of an interesting point Eugene Osovetsky of WebServious pointed out, he said that 1/3 of his time is spent on building product, 1/3 on building customers, and 1/3 on getting funding.
  4. Do due diligence: Get a good lawyer to protect your intellectual property (IP), setup your corporation, etc. Get an accountant, tell them about your business needs, ask them how to setup bookkeeping, and setup the process.
  5. Prepare for an emotional roller-coaster: One day you’ll be sailing the Cayman Islands with six strippers on a private yacht and on another day you’ll be realizing that the business you have poured your soul into is a failure.
  6. Expect more from lawyers and investors: While a lawyer can provide legal counseling and investors can provide funding, they should bring a whole lot more to the table. Lawyers have great connections to investors and they have data they only get. VCs should provide advice, connections, leads, etc. not just the funding.
Read More

I Quit Microsoft

December 8th, 2010 Posted in Entrepreneurship, Hacks, Random Thoughts
3 Comments »

I quit Microsoft. This means I am saying good bye to many things: stock options, stock awards, awesome health care, incredible gym membership, 401K contribution matching, a handsome salary, and most importantly, working with some of the smartest people in the world. I can’t emphasize the people enough. I get all the good things, I work side-by-side with the industry leaders in cloud computing and federated identity, they are driven, dependable, and much more… and none of the bad things, I don’t have to deal with politics, gossip, attitudes, or any of the typical office BS.

The economy is poor, unemployment is high, and I have a cushy job. I’m starting to look crazy for quitting. This warrants two questions: “why are you quitting?” and “what’s next?”

Why are you quitting? I’m quitting because it’s been my dream to have my own startup since I was 13-years-old.

To anyone who knows me, this comes as no surprise. I started my first consulting business when I was 16-years-old with my allowance money. I’ve had other profitable businesses with customers as big as the former Seattle Sonics and Universal Map Inc. I started teaching myself to program while I was still in elementary school; by the time I was in high school I programmed my own boot sector in assembly, plugin for 3D Studio Max, stereoscopic 3D imagine processing, Linux drivers, automated blind TCP/IP spoofing attack, and CGI in C++ (before PHP and ASP were around). Ahhh, the good ’ol’ hacking days. You get the picture: I love building what people want (and want to pay for) and I love building software.

It’s clear that I want to build a company. Building a great company isn’t something that can be done in the evenings; especially not while working for a company like Microsoft which already demands so much attention. I need to dedicate myself beyond the standard 9 to 5 to succeed.

What’s next? I don’t know exactly, but there are a few things that I do know.

I know I have passion for all the right things. While I am passionate about building software people want (and want to pay for), I also want to build something that goes beyond just my immediate talents. I want to build a machine which adds value to people and organizations, makes the world a better place, and makes a profit as a result. (Two interesting related articles: “In Defense of Entrepreneurial Passion” and “Why ‘Be Passionate’ is awful advice”).

I know that visionary companies were started without a product. One such example is Sony from “Built to Last”. I don’t need a product and I don’t need early success to build a company.

I know that I can listen to customers. I deeply buy into investing in customer development per Steven Blanks “The Four Steps to the Epiphany” before investing in product development. That is, I will commit to having customers lined up with checks in hand to buy my product before I even build the product.

I know that I can build software. I have been writing code for more than half of my life. I’ve also been responsible managing product development at Microsoft for over five years. I can deliver the minimal viable product on schedule with limited resources, and iterate rapidly to evolve the product. Relatively speaking, this is the easy part.

Having said all that, I haven’t really answered the question.

My options right now are endless. There are really a number of avenues I will be entertaining. First, I have a few product ideas that I am entertaining; I will drive those product ideas through the customer development process until I have something that sticks. Secondly, I will continue working with some friends on other ideas and exploring various markets and talking to people to see if there are opportunities outside of the scope of my current product ideas. Lastly, I would also consider working for another startup if I believe in the company and I get to exercise my desire to build something beyond me.

My last day at Microsoft is to be determined, but will be no later than Feb 25th.

Read More
Older Entries