Showing posts from July, 2017

Startups: You Don't Need a CTO (Yet)

"My technical co-founder just quit," she says, "and he took all of the product code with him.  Now I have to negotiate to get my product back."

"I had to fire my CTO last week," he says, swirling the coffee in his mug and looking around the coffee shop.  "The entire engineering team quit within a few days, so now I'm just hoping nothing breaks before I can hire some people to review the code and learn how it all works."

I hear stories like this all the time from the startups that I work with and from other startup mentors.  Companies who are just starting to get traction are suddenly paralyzed by a loss of technical leadership and lose precious time, money, and reputation strength as they rebuild.  The cause: hiring a CTO too early.

Every software company needs technical leadership, and it can seem especially critical in the early stages, but do you need a CTO right out of the gate?  Tradition (and perhaps investors) would say so, but experie…

Feeding the Elephant: Building for Enterprise Customers

In my last post, I told you how to identify the real customers of your software. Now let's talk about what you do if that customer is a large enterprise.

Many development teams think that if they worked for a “real” product company, then they would build a cool product, with features that they knew everyone would want, and the world would beat a path to their door.  “Real products predict what the market will want, they build it, and then everyone buys it,” they say.  “Better yet, they disrupt the market by building things that no one even knew they needed!  Why aren’t we doing that?”

Personally, I can think of one company that worked this way: Apple.  And even Apple had the Lisa, an expensive mistake that illustrated the high risks of the “artistic savant” approach to product development.  All other development teams have to actually talk to some customers, figure out what they need, and build it.  To make things more complicated, the voices of those customers vary widely depend…

Building for Your Customers

“Be more customer-focused.”
It’s the mandate of every product development team. We have customer advisory boards, customer relationship managers, customer support, and “voice of the customer” panels in our scrum-of-scrums. But do we really know who the customer is, or how we can best serve them? After two decades of building software products, I’m afraid that the majority of the time the answer is “No.”
Whether you’re building enterprise software or a mass-market consumer product, you need to understand your customer before you can build the best product for them, and to do that, you need to ask yourself a few questions: Do we know who our customer is?Do we really know what they need?Are we meeting those needs in the best possible way? Who is our customer, really? When you make commercial software, it’s easy to forget who will be using it, to confuse your user and your buyer. This is especially easy in enterprise software, where a few large customers often gain a disproportionately lou…