Interesting article on Medium this week:
Each day is given only 24 hours. Even with the bare minimum of coordination costs, cut down by your tools and your processes and your homegrown blend of agile, whole hours of that day are lost to meetings, status updates, course correction, revision, company chatter, building consensus, setting and measuring, iterating and reporting. Life decimates your team with unerring and unrelenting creativity.
Mark Suster has a great series about enterprise startups on his blog. Here are a couple excerpts from the 3 articles he wrote so far.
But the “no sales people” mantra isn’t what I’m here to take on. It’s the second belief system that is even more engrained and even more wrong. Many young startups are being advised not to have a professional services business and in my opinion this is a big mistake.
The line of reasoning goes, “Services businesses are not scalable and the market won’t reward this revenue so make sure that third-parties do your implementation or clients do it themselves. We only want software revenue.”
This is a huge mistake. If you’re an early-stage enterprise startup, services revenue is exactly what you need.
How to Make Sure Professional Services Don’t Take Over Your Software Company
I recently wrote a blog post in which I pointed out that many investors & advisors discourage enterprise startups from having a professional services (PS) business and I think this is a big mistake.
I think it’s important for enterprise startups to layer in professional services into your revenue stream. [...]
BUT! You don’t want to run the risk that having a PS business that takes your eye of off the ball of growing a large software business.
How to Sell Your Roadmap Without Selling Your Soul
When we published our roadmap to our platinum customers we would inevitably get some complaints that some features were coming too many quarters out and they preferred them done sooner.
There was an easy solution to meet their requirements and our own. We would allow them to accelerate some Q3/Q4 initiatives to Q1/Q2 if they would fund the development. Often 2-3 customers would band together to fund an accelerated plan.
Before you think it, this was not prostitution. These were always features we knew we needed to build anyways – we were just willing to accelerate / prioritize them.
I encourage you to go and read all 3 articles in full. They have plenty of useful and actionable advice.
Jason Fried over at SVN:
I’d say “Why does it matter right now? I’m not racing anyone today. I’ll do it right at the meet this weekend.”
“I’ll tell you why it matters” he’d say, sternly. “You play like you practice. Practice sloppy and you’ll play sloppy.”
I have seen this happen so many times, both in sports and in my professional life. Right now, my field hockey team is experiencing a very bad run : 9 losses and 2 draws out of 14 games played this year. Guess how much we practice? We don't.
The same is true with the projects we're working on. Once you've made a certain set of mistakes a number of times, you stop seeing them when you do them. They become a habit. Bad work habits are very hard to break.
An implicit message is the importance of having a coach who's there to point out your bad habits and force you to do things right. Whether while playing sports or in your job, having someone who is able to help you learn how to do things right is invaluable.
Fred Wilson at his best:
When everything goes well, you really don't need that much from a VC. Of course, I have added value in all of my winners. But its the ones that don't work that I have left my blood, sweat, and tears on. And that's the paradox of being a VC that cares. Which is the only kind of VC you want to work with.
A good article about when giving too many options becomes a bad thing:
Most of these options exist for historical reasons — whenever there’s a new feature, it often gets a checkbox to turn it off. The other common case is when a feature isn’t obviously useful to everyone, and it’s hard to make an obvious choice about whether to have it enabled by default or not — so we build in a switch.
I believe we have been subject to this shortcoming on a regular basis with XWiki too. It happens like this:
- Someone wants to rewrite an old feature or add a new one
- Someone else asks: "Shouldn't we keep that old feature available? Should we really ship this new feature?"
- People start arguing endlessly about whether or not the feature is going to be useful, most of the time without looking at any actual data about how the feature actually is being used
- Someone jumps in with a awesome suggestion: "Let's make it optional and provide a setting in the administration / configuration file!"
While this is great for legacy compatibility and ease of customization, it can quickly lead to overly complicated situations: "-The software isn't doing this! -Did you check whether option XXX and YYY were activated? -No, how do I do that? -Well, you just have to go to screen AAA, then update setting BBB...". You get the gist. As evidenced by Barry Schwartz in this TED talk, there is such a thing as giving people too many options to choose from.
It takes determined leadership to stand in, cut the crap and remove what's no longer needed. This kind of approach can be tough to enforce in the context of an Open-Source project. Advocates of democracy, openness and freedom, I hear you. I am sympathetic to your views. They even make logical sense.
The thing is, great design requires that you keep only what is strictly necessary to build something amazing:
Apple wanted so badly to make a stunningly light and thin computer that they ruthlessly chose body design and build precision over lots of USB ports and an optical drive. Those two features are damn useful, and at the time every other computer had them. But they simply couldn’t have made such a slim, lightweight computer without a move the earthcommitment to get rid of everything that got in the way of their goal.
Options give you an easy way out of tricky design decisions. This is why you need to take them out ruthlessly if you're serious about building a great product.
Truly innovative technology products have at their core some pretty amazing technology. And then there are products that are mostly a re-packaging of something that came before in a nice wrapping. Those should not be worthy of our time and attention. This is the point E. Gün Sirer is making in a recent blog post:
But it's critical to keep tabs on the ratio known as "glue versus thought." Sure, both imply progress and both are necessary. But the former is eminently mundane, replaceable, and outsource-able. The latter is typically what gives a company its edge, what is generally regarded as a competitive advantage.
So, what is Yahoo signaling to the world? "We value glue more than thought."
Not only does the organization need to learn how customers will acquire and use the product, it is also true that the product itself may not be exactly what the market wants. In other words, launching a product is not the same thing as achieving product market fit.
Interesting article about the role of Excel in the London Whale scandal:
To summarize: JPMorgan’s Chief Investment Office needed a new value-at-risk (VaR) model for the synthetic credit portfolio (the one that blew up) and assigned a quantitative whiz (“a London-based quantitative expert, mathematician and model developer” who previously worked at a company that built analytical models) to create it. The new model “operated through a series of Excel spreadsheets, which had to be completed manually, by a process of copying and pasting data from one spreadsheet to another.”
While all software breaks occasionally, Excel spreadsheets break all the time. But they don’t tell you when they break: they just give you the wrong number.
On the heels of Twitter announcing that they will shut down Posterous, Google just announced that Google reader will get the axe in about 3 months. It's the second time in quite a short timeframe that a free service I was using will be shutting down in just a couple weeks.
I was lucky enough to be able to switch to Posthaven promptly. So far so good, even though the service does not support yet many important features (Twitter sharing, I'm looking at you). According to its pledge, the service is for-pay and should hopefully stay alive quite a while.
I was lucky enough to stay at @edwk's house a couple years ago, where I was treated to a demo of his great feed-reading app, Feedly. Although I didn't like the way Feedly re-organized my Google Reader feeds, it looks like things have changed quite a lot since then.
I have already migrated to Feedly and the latest version of their interface is still as sleek. I have also installed the Feedly iPad app, I will test it as soon as I get home. Last but not least, Feedly is working on its very own feed-fetching backend, code-named "Normandy".
There's just one thing I look forward to: be able to pay Feedly for the service. Their choice to use Google App Engine for their new backend has to generate costs, and currently none of their applications costs anything. I don't mind paying for a service, in addition to Posthaven I also have an Instapaper subscription running.
Feedly, I want you to live: please give me a way subscribe for a fee!