Peter Nixey

What today’s Magic Pony acquisition means for Entrepreneur First and for London

peternixey2 — Mon, 20 Jun 2016 16:47:56 +0100

A few days ago I received an email from Rob Bishop, the CEO and founder of Magic Pony. The email said that as a shareholder of Magic Pony Ltd. I would shortly be expected to sign a series of documents agreeing to their acquisition by Twitter Inc. Today it was announced that the company was acquired in a deal that TechCrunch’s reported from unconfirmed sources as being worth up to $150,000,000.

The reason I was a Magic Pony stockholder was that three years earlier I’d received an email from Matt Clifford and Alice Bentick asking me to meet for dinner. Alongside Chris Mairs and Chris Wade they invited me to become one of Entrepreneur First’s new, part-time partners.

Away weekend with Magic Pony’s EF batch (many other great companies contained)

Magic Pony was one of the companies that came out of the EF batch I worked with. Rob and Zehan’s cutting edge work in computer vision and their success in recruiting an incredibly strong team of PhDs meant that today, only two years after the company’s inception, EF will reportedly make over a return of well over a hundred-fold on their initial investment. It is a massive credit to Rob and Zehan that they pulled off the technology and the exit and did both in less than two years since the company’s inception.

EF is similar to YCombinator in taking a small percentage of each business for their capital investment. However their investment model is strategically different and tactically evolved to cope with the limitations of the European market. YCombinator takes pre-formed teams of smart entrepreneurs with pre-existing business ideas and often pre-existing businesses. Matt and Alice at EF recognised though that such a constraint would fatally restrict the ability of Entrepreneur First to attract sufficient talent from the more sparsely-populated European technical scene.

They knew that seed investing would be a numbers game and to get scale they’d have to recruit talent directly and individually from universities and jobs. Their hypothesis was that it was possible to form teams before the founders had either an idea or a founding partnership. Magic Pony was a company formed by two very smart young men from exactly that hypothesis. Neither of them even knew each other before EF. Today their union was so significant that Twitter’s own founder, Jack Dorsey announced their acquisition.

Six years ago, Heroku became first of YCombinator’s $100,000,000+ acquisitions. There had been a few YC acquisitions prior to Heroku but it was the first really big one. Its sale to Salesforce signalled to investors that YCombinator was a very real investor producing very real companies. Heroku’s exit wasn’t an acquihire, there was something real happening here. Investing in YC companies was about more than simply fuelling the ecosystem. Investing in them meant real returns.

And YCombinator’s returns were about to get greater still. At the point Heroku exited, both Dropbox and AirBnB had already been funded by YC and were putting down roots that would come to be worth over $30Bn. Not only that but Patrick and John Collison, fresh out of their first, small YC exit with Auctomatic had only a few months earlier been accepted into YC with Stripe. There were already three Unicorns growing in the stable.

Heroku’s acquisition rang the bell that woke Silicon Valley’s angels from their slumber and accelerated everything to light speed. Funding rounds went from taking months to weeks or even days. Prices went up and YCombinator’s ability to fund even more companies increased. As more companies went through YC, attracted by the brand and the advice, so more exits happened, yet better founders were attracted and yet more unicorns emerged. Sam Altman now estimates that YC funds a billion dollar company once per 80 companies. Or to put it another way, twice a year.

Magic Pony’s acquisition should be ringing the same bells for investors in Europe. Magic Pony will not be the last exit in this range for EF and I have little doubt that within a few years we will see the fund’s first billion dollar company emerge. I would expect a smart fund to index invest across the whole of the emergent EF portfolio in the same way that Sequoia and A16Z started index investing across YC. Prices are cheap right now and it is still a buyer’s market.

There will be very big winners from these years. In time to come prices will increase and access will get harder. Companies will expect more from their investors. Right now they will demand only money. In years to come it will be harder for unknown Angels to even get access to the hot deals. Today is the opportunity to become in London what Chris Sacca and Ashton Kutcher became through those early years of YC and make a name as a brand-name Angel.

The companies coming out of EF now will be demanding real, valley-like valuations. And well they might. It takes capital to fuel such high growth. I know investors in London who thought that the Series A valuation of Magic Pony was too high. They stayed out and invested in companies they felt were cheaper. I find that a very strange strategy. Had they invested in Magic Pony’s series A, they would have made a 30x return. They could have invested at over twice the valuation and still made 10x. Staying out of it made them nothing. And had Magic Pony failed they wold have lost the same amount of money whatever the valuation was.

Seed investing in tech is different to seed investing in almost anything else. The returns and the timeframes are just so different. As a seed investor in high tech your job is to optimise for one thing and for one thing only which is being in the winning companies. I only fully internalised this when hearing Ron Conway speak. His point was that when you make 1,000x returns on your winners it only matters that you have 999 or fewer losers. When asked how he felt about frothy valuations he said he wasn’t too fussed. He observed that valuations go up and down with the heat of the market but don’t affect the logic of the investment itself. It never makes sense to stay out of a probable winner simply because the valuation higher than you prefer. Tech is not like property where investing over the market rate means you can never profit. Tech multiples are huge. Making 500x rather than 1,000x is neither here nor there. The only thing that matters is making sure you’re on the mega-ships when they dock.

After being approached by Coca Cola to start my new company, Copyin.com, I had to resign my role at EF. As an alum though I am incredibly proud of what Rob, Zehan and Entrepreneur First itself have achieved and what they continue to achieve. EF is the single most important force of change in the technology scene in Europe today. I am confident that its presence will ultimately result in billions of pounds of value and thousands of jobs created. These are exciting times and there are fortunes to be made for early investors, entrepreneurs and employees alike. All of the people coming into EF companies right now stand powerfully positioned to become the technorati of years to come. Well done EF, well done Chris Mairs who I know put a huge amount of work into this deal and most of all well done Rob and Zehan and their team. An amazing result all round.

Comments on Hacker News >

Is it the Wealth Gap that’s bad or the Empathy Gap that comes with it?

peternixey2 — Tue, 26 Jan 2016 18:15:02 +0000

There’s a a really interesting discussion unfolding right now between Paul Graham and Tim O’Reilly on the Wealth Gap and whether or not economic inequality is really a bad thing per se.

I used to believe that the argument against wealth inequality was unsubstantiated and largely fuelled by jealousy. I believed (and still do), that economic inequality is a natural consequence of increased economic leverage. If the most successful people are becoming more effective and the least successful remain consistently ineffectual then you get a divergence in wealth. If the baseline is zero and the top line goes up then the two of them diverge.

And it’s not just the rich who become richer. Over the last 50 years the whole world has become a much better place to live. Health, wealth and education are up across the board. That’s happened because our economies are more efficient and more effective. The people who run the businesses that drive those economies have benefitted proportionally. Is it really such an issue if a few people get rich so a lot of people can get wealthier?

I used to think not. Now I’m not so sure. Because what comes with a wealth gap is an empathy gap. And when people lack empathy they treat each other in ways they wouldn’t want to be treated themselves. Often those ways are bad and when you treat someone badly enough they dislike you. If you continue to treat them badly they hate you. And when people hate each other bad things happen.

In order to find out more I tried to read a book on the topic. I didn’t succeed because it annoyed me so much I had to stop reading it. Most of it was arguing that poverty was bad (obvious) and that wealth per se was bad (not true). Most of the arguments against disparity were that things would be better if the poorer had more cash. But, as Paul Graham points out, that is not the same thing as saying that inequality is bad. What it says is that poverty is bad. And that’s something that I don’t think anyone would argue with.

The book was annoying and convinced me of nothing. However I had a lingering, unsubstantiated feeling there was a fundamental danger in the haves moving further from the have-nots. It was actually only only when I watched Neill Blomkamp’s Elysium (an allegorical story of the US/Mexican dichotomy played out in a futuristic, dystopian earth orbited by a utopian, man-made paradise) that I realised what it was and how I’d already seen it play out my own life. When the gap gets too large, empathy dies. And when empathy dies things get very bad.

As a career entrepreneur, most of my adult life has been spent with very low and extremely unpredictable income. I never wanted for anything during childhood but as an adult I’ve put everything I’ve ever had into my businesses and there have been many, many months when the stress of pennilessness rang like tinnitus in my ears. When buying bread and milk spikes your cortisol you’re in a bad place.

Essentials are the least stressful part though. What really hurts is the discretionary spending and what kills you is the forced discretionary spending. Unless you hermit yourself (as I did for three years during my twenties), it’s hard to get away from the social impetus for that spending. When you would walk a mile rather than take a $2 bus ride, buying a round of drinks cuts you like a sword. I wanted to punch a guy in the face when he asked me for a $20, double Talisker. He had a well paid job as an engineer with Nvidia. I had $20,000 on a credit card. How could he not realise the position I was in. How could he not realise that I’d literally spent ten hours walking across the hills of San Francisco to save the money his whisky cost me.

Imagine you ordered a drink and when the bill came it cost you $500. Imagine how sick that would make you feel, how it would ruin your evening. I had so little money at that point that that’s exactly how I felt. It ruined my night and I honestly hated him for it.

And yet eight years later I did basically exactly the same thing myself. I was back in San Francisco. This time I was there as an advisor to the Entrepreneur First cohort. These were all 20-something, first-time, unfunded entrepreneurs. I’d organised for us all to go out to dinner in the Mission. We weren’t at a particularly expensive place but when the bill came, every single one of the fifteen people there wanted to split it item by item. I found it intensely annoying to end the meal in such a tedious way and dismissed it suggesting that we just divide by the number of people.

But then I remembered that each of them was on a stipend of $1,600/month. They had to use that money to fund both both themselves and their companies. Meanwhile I was making $1,000/day contracting. So whether I was up or down on a $30 meal didn’t really matter to me. I didn’t have any empathy with their situation.

Not only that but I also ate and drank more. They were all budgeting, I wasn’t. So I wasn’t just being unsympathetic, in my carelessness I was also getting this crew of scrabbling start-uppers to subsidise my splashy lifestyle. Only, that didn’t occur to me because I didn’t feel the pain of expenditure the same way they did. I forgot the same pain that would have hurt me viscerally seven (or even two) years earlier. Yes, I was That Guy (though I subsequently paid over my share).

The powerful thing about empathy is it stops you from accidentally hurting people. You feel their pain as if it was your own. And that stops them from them hating you. And that’s good for everyone. That guy in the bar hurt me and made me hate him because he didn’t empathise with my situation. I made those young entrepreneurs stressed because I didn’t empathise with theirs. And both those things happened because we were economically removed from each other and lacked empathy.

Empathy doesn’t care about absolutes, it’s only the relative that matters. If you’re all rich or you’re all poor then it’s all cool. It’s only when you’re different that things get screwy. I have a very successful friend who’s CEO of a company that you will have probably heard of. By any normal standards he’s very well paid but many of his friends have sold their companies and made tens of millions. He’s now no longer able to keep up with them and finds himself resenting how much they will spend on a holiday or a meal that leaves him high and dry.

Boo hoo I hear you cry, poor him. It must be so hard living on a decent salary and not able to keep up with centi-millionaires. But unless you’re earning less than $3,650/year then boo hoo, poor you. Because you’re already earning more than 75% of the rest of the world. How does anyone in the UK or the US have any soap box to stand on when 20% of the world lives on less than $365/year? The UK government gives job-seekers $4,200/year in cash alone and that’s aside from housing and healthcare which is of course free. If you live in the UK you made it into the top 25% most wealthy people in the world even before you got out of bed. Well done you.

But the fact that you’re richer than most of the world doesn’t matter because let’s be honest, what matters is how much you have relative to those around you.

When you feel the pain of financial stress you feel the pain of financial stress. Is the suicide of the man evicted from his bedsit any less stressful than the suicide of the man who can’t pay his children’s private school fees or the teenager who can’t afford the right trainers? Stress and distress are stress and distress, who are any of us to judge their intensity.

Any of us feeling poor would probably immediately feel better if we were hanging out with the Syrian refugees currently camped out in Calais. We’d be grateful just to have a country to call our own. Small comfort to the financially suicidal in their hour of need though. Were they “rich and entitled” or “poor and needy” as they left this world? It all depends on your perspective.

The reality is that as long as you’ve locked in the first two levels of Maslow’s hierarchy then it’s hard to say that you’re poor in absolute. But that’s not to say that you’re not poor relative to those around you and that’s not to say that that’s just as distressing. Fairness and equality is deeply, deeply hardwired. In this incredible experiment it’s shown that even monkeys will demand equal pay for equal work. Hardly surprising then that inequality enrages humans.

So while I always thought a wealth gap wasn’t a bad thing per se; now I’m not so sure. Maybe, like me at that dinner table, the larger the wealth gap, the less we notice when we take more than our fair share. And the less we notice ourselves doing things that make people hate us. Or hating people for things they never meant to hurt us. If the guy in that bar had been a student, I like to think he’d have never asked me for a $20 drink. If I’d been out to dinner with those entrepreneurs only two years previous I’d have been delighted to itemise the bill.

I’ve never met a wealthy person that hates the poor but I’m shocked by the number of people I know who hate the wealthy. I never really understand why since none of them have obviously suffered at the hand of the “rich”. But then it doesn’t have to be something obvious to add up. Like the annoying housemate who eats all your ketchup, it just has to be occasional, careless or callous to eventually accumulate into a ball of righteous fury.

So to come back to Paul’s essay I think that his points are right, it’s not the wealth gap per se that’s bad. However I do think that the Empathy Gap is a bad thing. And the Empathy Gap is truly a problem with the distance between the two ends of the spectrum and independent of where either of them are. And for that reason I think a Wealth Gap is probably a bad thing too.

Comments on Hacker News

Experienced founders feel their company’s pain. Inexperienced founders feel only their own

peternixey2 — Mon, 06 Apr 2015 18:43:31 +0100

Most people don’t enjoy pain. If I held your hand over burning candle you’d haul at me to pull it away again. You wouldn’t even need to see or know that it was a candle to react to it. If I crept into your room and held it under your hand as you slept, you’d still instinctively yank your hand away. We are hard-wired to avoid pain.

But while annoying, pain is also useful. If I entirely removed your sense of pain you’d start to suffer some pretty bad wear and tear. Pain is nature’s way of telling us to get out of danger. It’s good at keeping us from socially awkward situations like casually sawing off a finger while chatting to friends over a steak dinner.

Stress has a similar effect on us. It’s a stimulus that causes us to get work done and to get it down fast. We tend to exert it on ourselves and others to create a discomfort that gets things done. Stress is not nice but like pain, it’s a powerful motivator and when used carefully is a useful corrective influence.

Over the years I’ve noticed that experienced and inexperienced founders have very different ways in which they experience stress. Experienced founders feel stress from the things that are causing pain to their company. Inexperienced founders tend feel stress from the things that are causing pain to themselves. Experienced founders have nervous systems that are directly wired into their company’s pain: the company is a voodoo doll for themselves. When the company is hurting, however non-obvious it may be to the rest of the world, the founder hurts too. Inexperienced founders tend to feel only their own pain which is all too often a trailing indicator for that of the company.

A classic place where you see these differences is in the initial product release.

John-Rhys, a fresh-faced young founder from Swansea is building a new SaaS CRM system. John-Rhys used to work at an agency. He loves building software but he’s sick of building software for clients that won’t invest fully in design and he wants this CRM to be gorgeous. He knows exactly what he thinks the market wants and plans to make sure they’re perfect before releasing them. It takes him eighteen months to get the first version and it’s pretty stressful making sure that everything’s as attractive as he’d like. Eventually though he puts up the registration form and convinces TechCrunch to do the cover story. Sadly the product fails eight months later because customers wouldn’t use it without email integration and they ran out of cash before they could complete that.

Hannah, the founder of an ad-tech company based in East London, has done a couple of startups before. She’s built plenty of product over the years and her experience has been that excellence is simply what comes from repeated rounds of customer testing. She can’t wait to get the first feedback from her customers because she’s not entirely sure which features they should double down on and which they should cut. She also knows that given they have only eighteen month of runway, they will need to start fundraising in twelve. To be ready for that she needs at least eight-months of customer engagement. The four months before their first release is a pretty stressful period because there’s a lot to do and she breathes a sigh of relief when the first customer support tickets start rolling in. Eight months later she has five paying clients on the platform and confidently begins her Series A fundraising.

Both founders were stressed but while Hannah’s stress prompted her to get the product out and into users’ hands, John-Rhys’ stress caused him to lose a massive eighteen months before launching. It also meant he invested too deeply in aesthetic design instead of testing the product with users and discovering how critical email integration was while they still had cash to build it.

Hannah’s stress came from things that were painful to her company, John-Rhys’ stress came from things that were painful to him. John-Rhys simply wasn’t attuned to what was hurting his company.

It’s not easy to feel the pain of a company. Company’s are not human-like creatures you can easily empathise with. You can’t even anthropomorphise a face on them so how on earth do you empathise with them?

One technique for feeling your company’s pain is having a good picture of what a healthy, well-adjusted company should look like. And that means planning. Plan for and visualise what success should look like. Look at where you need to be by your next funding round or milestone and work backwards to see where that puts you today. Find companies that are similar to yours and see what their trajectories were. What are the metrics, the hires and the partnerships that it will take you to get there. What’s the lead time to get those? The clearer you can visualise where you need to be, the more you can feel the discomfort of not being there. No plan survives first contact with the enemy but failing to plan is planning to fail. It’s only once you have some sort of a plan that you can feel the pain that comes from knowing you’re not sticking to it.

Startups are inherently stressful places. Founders tend to consciously and subconsciously generate stress in order to spur themselves onward. I think it’s hard to get away from that - it creates the discomfort that forces you to do a lot quickly. Make sure that the stress creates an impetus to do what’s best for the company though and not merely from what is best for yourself. Wire yourself into the nervous system of your company. Use the stress to to pull your hand back out of the candle. Also you possibly shouldn’t let me into your room at night.

Read comments on Hacker News >

You are the DNA of your company. What you are it will become

peternixey2 — Tue, 20 Jan 2015 11:25:00 +0000

Everyone knows the importance of hiring well. Everyone knows that the people they hire will set the culture and the prospects of the company. Anyone who has ever worked in a company has seen that the characteristics of that company are the manifestation of the team that works there. The kindness, diligence, discipline and efficacy of the company all flow from the corresponding characteristics of the team that operates it.

Great people beget great people. However many entrepreneurs fail to grasp the corollary to that. They fail to realise that their strengths are the strengths of their company. And so are their weaknesses. Their work ethic, their skill set, their interests and their values will be the same skill set, interest and values that will manifest throughout the company. What the founders are the company will become.

It wasn’t until I was working to sell my first company that I really grasped the significance of this. I started to see that great engineers produced great engineering companies and that dreamers produced companies that never quite delivered on those dreams. And I also realised something very sobering. I realised that I didn’t have the DNA to build the type of company I wanted. At that point in time, my characteristics didn’t contain the characteristics of the company I wanted to build.

I think that my younger self thought I might find such characteristics in the people I hired (actually a younger me thought that he already had those characteristics). However Joseph Smarr, an amazing engineer once said to me that “it easy to hire down but very hard to hire up”. And so I realised that while I might get lucky, I should assume that my best characteristics would also be my limiting characteristics. They were both the best and the worst in those that I should expect to be able to hire.

At the time I was a saviour-driven entrepreneur. I believed in the saviour-feature, the saviour launch, the saviour investor, the saviour meeting. Many entrepreneurs think that way. Films teach us to believe that that’s how it happens. They start off with enthusiasm and gusto, have a serious setback a third of the way through that causes us to sit back and re-evaluate. Then, following an eye-of-the-tiger training-montage we go on to snatch the final prize in a flood of glory, Hans Zimmer orchestrals and wingman soundbites.

That’s not how real life works though and I was still to learn how destructive such a saviour outlook actually was. I was still to develop the stamina and focus it takes to do the many small and boring things that will never feature in any montage but on which a company is built. I was still to become the entrepreneur that was capable of leading the company that I actually wanted to build. I was still to become someone that *I* would aspire to work with.

I happened to be in Dropbox’s office when they went to pitch for Techcrunch 50. It was a high-visibility conference and if it had been me up there pitching I would have been prepping for the two days before, practicing and changing it up hour by hour. If ever there was a saviour moment to savour it was pitching for the finale of a big conference.

Drew and Arash, the Dropbox founders, did none of that. They spent the morning programming, they went to the pitch, fumbled it, took second place and then came straight back to the office to carry on working. Dropbox did nothing but work relentlessly, day-in, day-out on making the product perfect. Drew and Arash aren’t splashy people, they’re engineers and so they created an unsplashy company full of engineers. Their DNA replicated itself out and throughout their company.

Virgin, by contrast is a very splashy and flashy company. It’s sexy, adventurous and edgy just like Richard Branson. Zappos is a caring, community-driven company focussed on metrics, efficacy and culture building just like its founder, Tony Hsieh. These companies may be outliers and reflect extreme personalities but when you get close to most companies you see the strengths and values of the core team replicated out throughout the rest of the organisation.

It’s important to remember this as you build your company. However it’s critical to remember this when you conceive your company. It’s critical to ensure that what you expect to be special in your company is also what is special in you. Because if you create a company that’s critically dependent on engineering and your founding team doesn’t include engineers then you will have a very very hard time. Equally if you create a company like Jordan Belafort’s Stratton Oakmont and your team doesn’t include a ruthless, frothing-at-the-mouth-sales guy you probably aren’t going to sell a lot of penny shares.

SoleTrader.com makes websites for tradespeople. The websites do exactly what those tradespeople need and the company is growing fast and making a lot of money. However, if you’d have asked me in abstract whether the world needed another website-creator I’d have said no. If you’d told me that the founder wasn’t an engineer then I’d have said that the company had no chance at all.

But while Seb, the founder, wasn’t an engineer, he was a salesman. And for the first year he and his partner would each make 200 phone calls a day to builders, plumbers and electricians asking if they wanted a website. With a 0.5% conversion rate their job was the envy of no-one. But bit by bit they built up customers and wired the websites together using Wordpress. Today the company is doubling in size every few months and has a highly refined sales pipeline, lead identification process and customer on-boarding. The company grew because it played to the strengths of the founder. Those strengths were sales, not technology and they’ve built a strong business off the back of it. They use technology heavily and they’re now deepening their investment into it but that’s not what they’re really about, that’s not what differentiates them from their competitors.

So when you decide what company you want to build and what its unique differentiators will be, make sure that you already have those. Be loyal to what you’re unusually strong at and your company will reflect that strength. If you don’t have a particular strength (say engineering) then that doesn’t mean that your company won’t have an engineering component to it - just that you shouldn’t expect it to be the company’s key differentiator.

Play to your strengths. You are what your company will become. Make the most of your strengths and your business will do the same.

Comments on Hacker News >

This is the dream non-technical startup job

peternixey2 — Fri, 10 Oct 2014 10:28:00 +0100

I am a founder advisor to a company called RotaGeek. RotaGeek schedules staff for companies like O2 i.e. it makes sure the right people are in the right retail outlets at the right time of day.

The company launched four months ago and with only three employees, already has £150,000 in annual recurring revenue. Based on the current inbound leads alone it looks like it’s going to have £1M in recurring revenue by the end of next year.

This is the real deal. I’ve been doing startups for ten years and never seen anything like this.

Chris, the founder, is a badass but totally run off his feet right now and needs someone very capable and bright to complement the work he’s doing. She or he needs to be Chris’ “right hand person” and will end up holding a very significant position in the company and doing many things. The company is a different place every week and this role will be very different in five months time.

We are looking for someone who is very smart, has a track record of doing hard things that demonstrate their ability to consistently work and achieve and who is able to write and present extremely well. The role will involve everything from working through UX and analytics in improving the signup flow to going out to present RotaGeek at pitch events to handholding multinationals through their onboarding process.

If you’re smart, hard working and have ever approached a startup suggesting that you might be good for “biz-dev or marketing” then this may be for you. However you need to apply soon: we want to appoint this person yesterday.

If you are that person or you know that person, please tell them to get in touch with Chris directly: chris at rotageek dot com.

Your application should include evidence showing us how you’re smart and evidence that you’ve done hard things (whatever those hard things may be). Also include any public profiles - LinkedIn, Twitter, Blog etc.

Mail us.
- Peter

Brojures can now be embedded

peternixey2 — Thu, 26 Jun 2014 14:42:00 +0100

Which while completely orthogonal to anything else I write about is kind of cool :)

A counterpoint to Jessica Livingston's advice: Why Startups Should Use Marketing as Sonar

peternixey2 — Sun, 08 Jun 2014 17:21:00 +0100

Jessica Livingstone recently wrote a very good article for the WSJ on Why Startups Need to Focus on Sales not Marketing. Her point was that early companies do much better by making their products work really well for a defined audience than by distracting themselves with high-scale but low-fit marketing.

Only a few days earlier I had been enthusiastically advocating exactly the opposite advice to the team at Entrepreneur First. I feel that startups should pay extremely close attention to marketing and do so as an ongoing discipline. I think that one of the biggest dangers to early stage startups is getting into a local market-minima and that marketing is an essential tool to help avoid that.

One of the team, Alex, wrote to me to ask whether the two points were at odds with each other and if not why I would stand by my original statement. I don’t and I do. Here is why.

It is very important to focus on making a product work really well for clearly identified customers. It’s painful and takes longer than you expect. But it also forces you to make software that is genuinely useful. As Jessica points out, marketing is painless and shields you from the cold reality (and insight) of rejection. A depth-first approach also tends to correlate with successful products. Or as Paul Buchheit says, “it’s better to make a few people really happy than to make a lot of people semi-happy”. Worth noting that this isn’t the same thing as causation but for those of us who value building beautiful product, encouraging nonetheless.

However in the product-focussed, early-stage (pre YC) teams that I see, the real risk is not that they waste time or money on marketing. The real risk is that they end up optimising for the few users who are most easily accessible to them. Instead of exploring the wider market, these teams relentlessly iterate their product for a small number of friends, family and customers who don’t necessarily even want their product. They just happen to be accessible users.

The real risk for a product team isn’t failing to make good product, it’s failing to find a market that wants it http://t.co/4fdvhuNP9f
— Peter Nixey (@peternixey) June 9, 2014

Marketing is traditionally a tool to help companies scale sales. It allows them to reach out to a lot of people and either sell them directly or soften the ground for a purchase later on.

That scalable outreach is super important to startups too; not as a sales tool but as an exploration tool. Marketing is a way for startups to quickly gauge demand for their product across one or more marketplaces. It’s a way for startups to explore the territory and find their beach heads. In more mature companies, marketers complement the sales team. In early startups they should be cartographers, and complement the product team. Before you can make something work perfectly for an individual customer you need to find the individual customer to perfect it for.

Marketing in early startups is super important. Not for growth but for exploration. Marketing is a startup’s sonar http://t.co/B1K2FbogiI
— Peter Nixey (@peternixey) June 10, 2014

“Startup marketing” does not mean thousands of dollars spent on adwords budgets or expensive trade show stands either. Startups are inherently interesting and should get involved in the communities they’re designed to service. If you’re a developer and your community is Hacker News then you have it easy. Companies like Stripe and statuspage.io absolutely nailed their HN marketing. If your target market is Mums then get stuck into Mumsnet, if it’s teaching then get stuck into the teaching community. Some of these communities are in forums, some are on Twitter some are probably just physical. Any which way though your primary marketing is simply Getting Involved. It won’t get you all the way but the relative ROI is huge.

One of the companies I advise, Rotageek, provides excellent scheduling software for organising staff schedules. The team spent years honing the product and making it right for the NHS here in the UK. One of the founders, Chris, worked in emergency medicine and saw the pain and cost of manually organising staff. Being an entrepreneurial sort, he teamed up with a friend to create a piece of software to address that. He knew the problem intimately and worked hand in glove with the NHS, evolving the product and optimising it for their needs until one day he realised they just weren’t going to pay for it. They would happily string him along and may eventually, possibly have bought but that point would have been long after the company finally ran out of runway.

However the moment that Rotageek switched from optimising the product for the NHS to casting their net out wider, they started to find companies who really were hungry for the software and more than willing to pay. The team is now scaling for a huge rollout and all because they started marketing the product widely enough to find people who really wanted it. Even now they still only have a relatively small market sampling. While retailers are extremely receptive to Rotageek, they may not end up being the best market for the company either. Without reaching out to new markets and without casting their nets wider, the company will never discover that.

One of the hardest and also the most useful things I’ve ever done was door-to-door book sales in West Virginia. I did it with a friend as a summer job at University. We learned a huge amount about selling and how to sell. The sales scripts and the sales school were both brilliantly designed but despite all the technique, the scripts and the schooling, one simple lesson was hammered home again and again: “The quickest way to convert a disinterested customer into an interested one is knock on five new doors”. The point was that finding the people who really want to buy from you is more lucrative than obsessing over those who don’t. To find that customer, the one that’s really hungry for you, you need to first of all knock on a lot of doors.

Most teams focus on Product Search & optimising product. Just as important is Market Search & finding optimal market http://t.co/B1K2FbogiI
— Peter Nixey (@peternixey) June 9, 2014

You should absolutely go deep and optimise for your target market be careful not to optimise prematurely. There is someone for everyone on the internet. You can find people who are willing to eat you and even people who are willing to be eaten. When you find those customers who really want to you (hopefully not for dinner) then follow Jessica’s advice: go deep and deliver exactly what they want. Until then though, remember Annie Lennox’s advice and that “everybody’s looking for something”… “Hold your head up, keep your head up, movin’ on”.

Comments on Hacker News

Introducing Objectives, Goals and Strategies

peternixey2 — Thu, 05 Jun 2014 10:50:00 +0100

As with my previous post this is taken from an email I sent round to our team today

I’ve spoken about this with all of you individually now but I’d like to get it down and into Copyin too.

Up until recently we’ve been using “2-week plans” to give us each a longer horizon on the work we’re doing. Those have been combined with weekly “Plans, Progress and Problems” reports to give us a way to plot and chart our progress.

As an early startup, we operate on such a tactical, day-to-day basis that the two week plans were originally a useful way to help orient ourselves with where we each wanted to go in the “longer” term. However once we introduced weekly PPPs they started to feel redundant. The two week plan was turning into just twice a PPP and not adding any value to us.

The PPPs do an excellent job of making sure we’re moving forward they don’t really do a lot to check that we’re going in the right direction. Which is where Objectives, Goals and Strategies come in.

Objectives goals and strategies are a way of determining the exact value-add that we want to commit to (objective), how we plan to deliver the value add (strategy) and whether we succeeded in doing so (goal).

Objectives

The qualitative outcome we want to achieve e.g.

make sure that people stay active on Brojure
increase the number of people being exposed to Brojure
make the editor easier to use

Goals

These are the hard numbers that determine whether we have actually met our objectives. They’re a way of making our objectives achievable and failable.

(examples of goals that relate to the above objectives)

increase the proportion of new users who create a 3rd Brojure from 1% to 20%
increase traffic to the site from 500 uniques a week to 5,000 uniques per week
reduce the time it takes to create a Brojure (with known content) from 15 minutes to 5 minutes

NOTE - these should be achievable (not ridiculous) and also failable (you should be able to tell whether you actually achieved them. e.g. “make editor better” is not failable)

Strategies

These are the ways in which we are going to delivery our goals.

Note that the strategies are the ways in which we achieve our goals. They are not the goal itself. Failing to recognise this distinction is why many people and companies remain busy without really achieving anything. They assume that the work is the goal. Working is not the goal, it is merely a means to achieving the goal.

Let’s look at possible strategies for achieving the goals we set above:

Possible strategies for increasing # users who create 3rd Brojure from 1% to 20%

after each Brojure send them an email with a trick they can use for a new Brojure and a prompt to start the next one
pick a vertical and funnel users through 3 particular uses of Brojure for them e.g. for a restauranteur encourage them to produce: 1 Brojure for their menu, 1 Brojure for Private Events, 1 Brojure for the restaurant’s history (sounds like a crappy strategy to me but it is at least an example of one!)
add a “to do list” in the editor encouraging users to “complete their to-dos” one of which is making 3 Brojures
allow people to copy Brojures and tweak them for someone new

Possible strategies for increasing traffic to site

guest blog on other people’s publications
buy google adwords (needs further constraints to ensure that the strategy is economically viable)
make identifiable improvements to SEO
get guerrilla and go into communities to spread the word

Possible strategies for decreasing time it takes to make Brojures

fix image upload bug
allow people to copy an existing Brojure to create a new Brojure
pre-load Brojures with content
allow people to save content snippets that can be injected into new Brojures
add more Javascript interaction to the editor to literally increase editing speed

What Objectives, Goals and Strategies actually do for us

The idea is that each month we will decide on our actual objectives. This is one of the most important parts of the process. It’s very easy to just churn through work without moving forward and so before we decide what we’re going to do we first decide what we want to achieve. Product is one place that can benefit hugely from this part of the process. It’s incredibly easy to queue up lots of features without any of them actually impacting us and end up with a set of features for the sake of features.

Once we’ve done that we then get honest with ourselves and ask what will tell us whether we achieved that outcome. We set our goals.

Finally we look at the strategies we’re going to use for achieving those goals. How will we execute?

OGSs will be set at the start of each month

The Objectives will become something that will require solid teamwork from us. If we take an objective like “increase Brojure completion rate” then it may require Dash to create an email strategy, Peter to implement changes in the editor and Tomas to design them. Similarly “Increase the number of people engaging” may mean Ollie has to do do more phone calls but that Dash needs to create a new sign-up email type and that Tomas needs to tweak the landing page design.

This is nice in that it begets collaboration which is fun. However it could also go badly wrong. If we choose goals badly they will be dependent on multiple people and we could fail on all OGSs simply because a critical member of the chain was not able to give their support to all of the strategies they were required for. If Dash is on the hook to do an email component for every other person’s strategy then he could end up over-committed. If he’s overcommitted then he won’t succeed and everyone fails. Whose fault was this though? Who can correct it when it becomes clear that it’s starting to happen? Not Dash’s because he was over-committed, not everyone else’s because it was Dash who failed to deliver. This is NOT a situation we want to find ourself in (or put Dash in).

If people can’t independently deliver their goals then they get demotivated & tasks sink to the lowest common blocker http://t.co/CM9l5aSzoD
— Peter Nixey (@peternixey) June 5, 2014

Goals should hold individual people (or teams but at our scale it will mostly be people) responsible for delivering and should afford them the autonomy and resources to do so.

Objectives will be set company wide, goals will be individual

For this reason we will decide on company wide objectives but each goal will relate to a particular individual. We will choose goals such that individuals can execute on them, can take credit for them and can can be held responsible for them.

There is one exception to this in that Tomas and I have discussed this and because his design work is currently so strongly coupled with my dev work we will work as a unit on product. I’ll go on the hook for both of us :)

Any questions, concerns, objections just hit me up or reply to this email.

Thanks team,
Peter

The most important question in a startup: Am I being proactive?

peternixey2 — Thu, 15 May 2014 15:12:00 +0100

This is taken from an email that I sent out to our team earlier today.

Some jobs in life come to you - answering phones, answering emails, responding to requests. They turn up and you process them. As long as you spend the day processing them then you’ve done your work. These tasks keep us in place, they stop our businesses unravelling, they maintain our status quo. If we already have a company, a revenue stream and a business model then that is exactly what we want. If we do not then it is exactly what we do not want.

In a big company, your job is to maintain the status quo. If all eBay does for the next decade is continue to be the top online marketplace and make 9% profit off all transactions they will have succeeded. Most of that work is reactive - keep competitors at bay, acquire them when they get too feisty, make sure systems don’t go down: as a friend from eBay once told me: “the main thing people care about here is making sure we don’t fuck it all up”.

However if, over the next 10 years, all our little startup does is to keep 100 users on the system with one super-user and and ten more somewhat engaged, then we will have failed spectacularly. We don’t yet have the luxury of having anything to fuck up. We dream of the day when our fuck-ups have consequences. Our fuck-ups go sadly unnoticed.

Big companies fear change because it usually means something’s gone wrong. Startups are entirely the opposite. If startups are not changing then they are dying. Everything we do is about changing numbers not maintaining them, everything is about building product, growing users, building momentum, increasing engagement. None of those things are about maintaining the status quo, none of them are about not screwing up; all of them are about gaining new ground.

We do not fail in unsuccessful attempts to take new ground, we fail in not making those attempts in the first place.

Reactive tasks are about maintaining your current position, they are about not losing ground, they are low risk. You know they’re feasible because you already hold that position, you know what the ground feels like under your feet. You know that you can probably complete that task without failing. Pro-active tasks are quite the opposite. They require taking new ground and taking ground that you’re not sure can even be taken.

“in a startup, absolutely nothing happens unless you make it happen” - @pmarca http://t.co/v2TbP8yoX2
— Peter Nixey (@peternixey) May 15, 2014

Being proactive and making this happen is hard and comes hand in hand with failure. It means going out on a limb, doing jobs that risk not having any worthy outcome, doing things that may just fail to work altogether. It also requires being wrong and ideally being wrong 50% of the time.

Most of what a startup does is exploration and testing. Our goal is to find a repeatable scalable business model, our job is the search for that. We are literally discovering what works and what we can successfully repeat. We are figuring out what product our users want, who wants it most and how we can reach them. Once we have tested that then we can repeat it but first we must test it.

Information theory tells us that the optimal testing strategy yields positive outcomes 50% of the time. If on average you’re right more than that then you waited too late to test, less than that and you tested too early. The goal of testing is not to prove that you are right it is to see *if* you are right.

But optimising to be right 50% of the time means optimising to be wrong 50% of the time and that is 100% more of the time than most people can handle.

It’s easy to respond to an email, you cannot fail. It’s there, it’s asking you to respond to it, you already know there’s an audience waiting to read it you can’t go wrong. It’s far harder to risk the rejection that comes with cold calling a customer who may not want to hear from you. Far harder to report the 0% clickthrough rate from your latest, experimental email campaign or that the blog post you spent a day writing only ended up with 10 visits.

But these are the jobs that actually move us forward. These are the jobs which, while infused with risk, are also laced with sparkly rewards. These are the crazy email campaigns that may yield a 50% clickthrough rate, the blog post that happens to resonate and generates 60,000 visitors. These are the alpha-team tasks that parachute you into new ground and from which all of the reactive tasks subsequently unfold.

These jobs are proactive not reactive. It is the outcome of these jobs that form the anecdotes we tell people at parties, they are what go into our investor decks, they are what we feed the press in interviews. These are the forays that build our company.

So - as you put jobs into your daily to-do list, ask yourself: “is this proactive or reactive”? If it’s the former and it’s “tangible, fail-able and do-able" then it’s probably an excellent task. If it’s not then perhaps it really does need to happen but also ask yourself whether there is another way that you to spend that time that really moves the company forward. Because maintaining the status quo means maintaining a non-existent business. We are about change.

Comments on Hacker News

How to build a product that takes over the world

peternixey2 — Tue, 06 May 2014 15:25:00 +0100

I love this early interview with Mark Zuckerberg. I remember seeing it when it came out in 2005 and being impressed, even then, with how humble and pragmatic the vision for the service was.

The company is early enough that it’s still college-only and called The Facebook. It’s so small that you can see Dustin Moskovitz doing a kegstand in the background without any PRs diving in to tackle him out of the shot.

The thing I really love about the video though is Mark’s total focus on product (The Facebook) and service, and his utterly pragmatic view for how it can potentially evolve.

When asked, “Where are you taking Facebook?” he gives the following answer:

“There doesn’t necessarily have to be something more, a lot of people are focussed on taking over the world, doing the biggest thing, getting the most users.

I think that part of making a difference and doing something cool is focussing intensely. There’s a level of service that we could provide when we were just at Harvard that we can’t provide for all of the colleges and there’s a level of service we can provide as a college network that we couldn’t provide if we went to other types of things.

So I really want to see everyone focus on college and create a really cool college directory product that’s very relevant for students and has a lot of information that people care about when they’re in college. I don’t know what that is and it’s not everything that’s on The Facebook now”.

“There doesn’t necessarily have to be more, I want to focus on college & create a directory prod. that’s relevant for students” Zuck 2005(!)
— Peter Nixey (@peternixey) May 6, 2014

A more powerful and succinct endorsement for PG’s advice that founders should make something people want, do things that don’t scale and offer surprisingly good customer service would probably be hard to come by.

Here’s the video:

How to be a great software developer

peternixey2 — Tue, 22 Apr 2014 13:11:00 +0100

Disclaimer: This is a very long piece, much longer than I would normally write on any subject. I have edited it back but on sending it to friends to read they agreed that there was no one bit that should be cut. I hope that you feel the same.

If there’s one thing that software developers care about, it’s becoming even better software developers. Where do you start though? Should you accumulate the bells and whistles: deepen your knowledge of Node and no-sequel? Should you rote-learn the answers to the profession’s gateway questions and be able to produce bubble sort or link shortener algorithms on demand? Or are there perhaps more fundamental roots that you can put down?

I believe that your seniority and value as a programmer is measured not in what you know, it’s measured in what you put out. The two are related but definitely not the same. Your value is in how you move your project forward and how you empower your team to do the same. In fifteen years of programming I’ve never had to implement a bubble sort or a link shortener. However I have had to spend thousands and thousands of hours writing and refactoring account management tools, editing suites, caching logic, mailing interfaces, test suites, deployment scripts, javascript layers, analytics architecture and documentation. These were the things that mattered, the completion of these were what moved us forward.

Those humble components are the bricks and mortar of projects and take hundreds or thousands of hours of hard work to assemble. And even though they combine to form complex systems, they themselves should not be complicated. You should aim for simplicity and over the years I have learned that simplicity is far more easily attained by time spent working and refactoring than hours of pure thought and “brilliance”.

Simplicity and excellence are most reliably attained by starting with something, anything, that gets the job done and reworking back from that point. We know this is true of companies and the concept of the MVP is burned deep into our consciousness. So too with software. Start with something ugly but functional and then apply and reapply yourself to that ugly and misshapen solution and refactor it back into its simplest form. Simplicity comes far more reliably from work than from brilliance. It comes more predictably from code written, than from thought expended. It comes from effort.

“Your value as a developer is measured not in the height of your peaks, but the area under your line” http://t.co/6JMyGvGuzl
— Peter Nixey (@peternixey) April 22, 2014

It is all too easy for smart lazy people to flash spikes of brilliance and wow their contemporaries but companies are not built on those people and product does not sit well on spikes. Companies are built on people and teams who day in, day out, commit good code that enables others do the same. Great product is built by work horses, not dressage horses.

Years after Joel coined the term “Rockstar Programmer”, it lives on along with the misapprehension that companies need such geeky micro-celebrities in order to do anything. While those characters do exist there aren’t many of them. When you do find them they’re often erratically brilliant - astonishing at the things that interest them but hopeless at working consistently or smoothly with their team.

Not only is their output erratic but their superiority is aspirational and infectious. Their arrogance bleeds toxically into the rest of the team. It signals loud and clear that if you’re smart enough you choose when you work and what you work on. You become a “Developer in Residence”. And you not only soak up a salary but you distort the values of those who work around you.

So the reality is that in all likelihood you and your team will depend, should depend not on those who think they are “Rockstars” or “Ninjas” but on reliable people who work in reliable ways.

Great developers are not people who can produce bubble sorts or link shorteners on demand. They are the people who when you harness them up to a project, never stop moving and inspire everyone around them to do the same. Fuck Rockstars. Hire workhorses. Here’s some ways to become one:

Name your functions and variables well (write Ronseal Code)

Such an incredibly simple place to start and yet I think it is one of THE most important skills in programming. Function naming is the manifestation of problem definition which is frankly the hardest part of programming.

Names are the boundary conditions on your code. Names are what you should be solving for.

If you name correctly and then solve for that boundary conditions that that name creates you will almost inevitably be left with highly functional code.

Consider the function:

It tells someone almost nothing abo

ut what it’s going to do or how it’s been implemented in the code. However:

tells someone exactly what’s going to happen. It’s also a good indicator as to what’s not going to happen. It tells you both what you can expect the method to do but also how far you can overload that method.

A developer might happily refactor “process_text” to not only convert text to HTML but to auto-embed videos. However that may be resolutely not what was expected in some of the places that function was used. Change it and you’ve created bugs. A good clear name is a commitment to not just what a function does but also what it won’t do.

Function names create contracts between functions and the code that calls them. Good naming defines good architecture http://t.co/6JMyGvGuzl
— Peter Nixey (@peternixey) April 22, 2014

A good function promises what it will deliver and then delivers it. Good function and variable naming makes code more readable and tightens the thousands of contracts which criss-cross your codebase. Sloppy naming means sloppy contracts, bugs, and even sloppier contracts built on top of them.

It’s not just functions that you can leverage to describe your code. Your variable names should also be strong. Sometimes it can even be worth creating a variable simply in order document the logic itself.

Consider the line:

It’s pretty hard to figure out what the hell is happening there and even once you have done so, it’s not 100% clear what the original author was trying to achieve with it. The variable names are horrible and tell you nothing.

The “and not” statement is always confusing to read (please never write “and not” clauses which end with a noun) and if your job was to refactor this code you’d have to do some acrobatics to guess exactly what the original intent was.

However, if we change the variables names into something more meaningful then things immediately start to become clearer:

We can go further still and forcibly document the intent of each part of the if statement by separating and naming the components:

It takes some courage to write a line like “user_is_recently_created” because it’s such fuzzy logic but we all do it at times and owning up to that helps inform the reader about the assumptions you’ve made.

Notice also how much stronger this approach is than using comments. If you change the logic there is immediate pressure on you to change the variable names. Not so with comments. I agree with DHH, comments are dangerous and tend to rot - much better to write self-documenting code.

The better code describes itself, the more likely someone will implement it the way it was intended and the better their code will be. Remember, there are only two hard problems in computer science: cache invalidation, naming, and off-by-one errors.

“If you want to be a great developer, make sure you write Ronseal Code that does exactly what it says on the tin” http://t.co/6JMyGvGuzl
— Peter Nixey (@peternixey) April 22, 2014

Go deep before you go wide - learn your chosen stack inside out

Very few programming problems are genuinely new. Very few companies are doing technical work that hasn’t already been done by 50 teams before them. Very few problems attract Stack Overflow eyeballs that haven’t already seen them somewhere else before.

For that exact reason, the majority of the things you are trying to do have already been solved by the very stack you’re already using. I once refactored 60 lines of someone else’s Rails code to a one line using the delightfully simple and powerful methods that Rails ships with.

“Most programmers waste huge amounts of time by lazily re-creating implementations of pre-existing functionality.” http://t.co/6JMyGvGuzl
— Peter Nixey (@peternixey) April 22, 2014

Not only do they waste time but they create verbosity and errors. Their code requires new documentation to describe it, new tests to monitor it and it makes the page noisier and harder to read. Like any new code, it’s also buggy. War-tested (and actually-tested) stack code is very seldom buggy.

If you are a Ruby developer take time to learn Ruby, especially the incredible range of array methods. If you are a Node developer take time to understand the architecture, the methods and the mindset of Node, if you are an Angular developer go right up to the rock-face and understand the logic behind of the incredible architecture the core team is forging there right now. Ask before you invent. You are walking in the shadows of giants. Take time to find their tracks and then marvel at how beautifully they have been built. Because if you don’t, you simply punt the problem downstream and someone will just have to figure out why the hell you chose the sub-standard path you did.

Learn to detect the smell of bad code

Something I’ve noticed in programmers who are good but who have plateaued is that they simply don’t realise that their code could be better. That is one of the worst things that can happen to your personal development. You need to know what has to improve before you can figure out how to improve it. Learn both what good code looks like and what bad code looks like. It is said that grand chessmasters spend proportionally much more time studying previous other good chess player’s games than the average players. I’m quite certain that the same is true for top developers.

An important part of your improvement arsenal is your ability to detect bad code - even when it’s only slightly bad or perhaps “a bit smelly”. Smelly code is code which, while you can’t quite articulate why, just doesn’t feel right.

It may be that you’ve used 60 lines of code for something which feels fundamentally simpler, it might be something which feels like it should be handled by the language but has been manually implemented instead, it might just be code that is as complicated as hell to read. These are your code smells.

It’s not an easy thing to do but over the years you should learn what bad code smells like and also what beautiful code looks like. You should develop an aesthetic appreciation for code. Physicists and mathematicians understand this. They feel very uneasy about an ugly theory based on its ugliness. Simplicity is beautiful and simplicity is what we want.

The truth is that the truth is sometimes ugly but you should always strive for beauty and when ugly is the only way, know how to present it well. If you can’t create beautiful code, at least create Shrek code but before you do either you need to develop your sense of smell. If you don’t know what good code looks like and know what bad code smells like then why would you ever improve it?

Write code to be read

I once heard Joel Spolsky say that Stack Exchange optimises not for the person asking questions but for the person reading the answers. Why? Because there are far more of them than the single person who asks the question - utility is maximised by optimising for readers, not questioners.

I think you can view code in a similar way. It will be written just once by you and you alone. However it will be read and edited many many times, by many others. Your code has two functions: the first is its immediate job. The second is to get out of the way of everyone who comes after you and it should therefore always be optimised for readability and resilience.

“Write your code through the eyes of someone who is coming at it fresh in a year’s time.” http://t.co/6JMyGvGuzl
— Peter Nixey (@peternixey) April 22, 2014

What assumptions have you made, what do your methods actually return, what on earth does that quadruple nested if / else / and not / unless, statement actually select for? Sometimes you’ll need more than just good variable naming and you should ring fence it with tests but do what it takes (and only just what it takes) to make it durable. Great code is code that does its job and that continues to do its job even when git blame returns a who’s who of your company payroll.

Write every line to be read through the eyes of a disinterested and time-pressured team mate needing to extend it in a year’s time. Remember that that disinterested and pressured team mate may be you.

Weigh features on their lifetime cost, not their implementation cost

New developers want to explore and to play. They love the latest shiniest things and whether they’re no-sequel databases or high concurrency mobile servers and they want to unwrap all the toys as fast as possible, run out of the room to play with them and leave the mess for the next dev to clear up.

Dogs aren’t just for Christmas and features aren’t just for the next release http://t.co/6JMyGvGuzl
— Peter Nixey (@peternixey) April 22, 2014

Features and architecture choices have maintenance costs that affect everything you ever build on top of them. Abstractions leak and the deeper you bury badly insulated abstractions the more things will get stained or poisoned when they leak through.

Experimental architecture and shiny features should be embarked on very carefully and only for very good reasons. Build the features you need before the features you want and be VERY careful about architecture. Save toys for side projects. Every component you invent, every piece of bleeding edge, fast changing software you incorporate will bleed and break directly into your project. If you don’t want to spend the latter stages of the project doing nothing but mopping up blood then don’t use it in the first place.

Or, as a friend once tweeted

Just use Postgres. Stop being a hipster, and just use Postgres.
— Tony Million (@tonymillion) December 29, 2013

Understand the liability AND the leverage of Technical Debt

Technical debt is the code you write which, while sub-optimal, gets you to where you need to go. It’s the errors which, while annoying, are still sub-critical. It’s the complexity of a single-app architecture when you know that the future lies in service-orientation, it’s the twenty-minute cron job which could be refactored to twenty seconds.

The cost of these these not only adds up but it compounds. Einstein once said that “there is no force so powerful in the universe as compound interest”. Equally there is no force more destructive in a large software project as compounding technical debt. Most of us have seen (or built) these projects. Codebases where even the smallest change takes months of time. Codebases where people have lost the will to write good code and hope only to get in and get back out without bringing the site down.

Technical debt is an awful burden on a project.

Except when it’s not.

Like all debt, when used correctly, technical debt can give you tremendous leverage http://t.co/6JMyGvGuzl
— Peter Nixey (@peternixey) April 22, 2014

Not only that but technical debt is the best type of debt in the world because you don’t always have to pay it back. When you build out a feature that turns out to be wrong, when you build out a product which turns out not to work, you will drop it and move on. You will also drop every optimisation, every test and every refactoring you ever you wrote for that feature. So if you don’t absolutely need them; don’t write them. This is the time to maximise your leverage, leave gaps, ignore errors, test only what you need to test.

In the early stages of a product or a feature, the likelihood is that what you are building is wrong. You are in an exploratory phase. You will pivot both on product and on technical implementation. This is the time to borrow heavily on technical debt. This is not the time to fix those sporadic errors or to do massive refactorings. This is the time to run through with guns blazing and keep firing till you burst out the other side.

When that happens though; when you’re sure that you’re in the right place and out the other side then it’s time to tidy up and to strengthen your position. Get things in good enough shape to keep on rolling, repay enough of the debt to get you on to the next stage.

Technical debt is like so many other things in a startup, a game of leapfrog. Your initial code is scouting code. It should move you forward fast, illuminate the problem and the solution and give you just enough space to build camp. The longer you stay, the more of the system that camp has to support the bigger and stronger you build it. If you’re only ever staying for a week though, don’t burn time laying down infrastructure to support a decade.

Check and re-check your code. Your problems are yours to fix

Engineers who “throw code over the fence” are awful engineers. You should make sure your code works. It’s not the testers’ job and it’s not your team-mates’ job. It’s your job. Lazily written code slows you down, increases cycle times, releases bugs and pisses everyone off.

If you constantly commit code that breaks things then you are a constant tax on the rest of your team http://t.co/6JMyGvGuzl
— Peter Nixey (@peternixey) April 22, 2014

Don’t kid yourself that you’re anything less than a burden and get it fixed.

Do actual work for at least (only) four hours every day

For all the talk about self optimisation, focus and life hacking that goes on amongst developers, the simple truth is that you don’t need to do that much work to be effective. What really matters is that you do it consistently. Do proper work for at least four solid hours each day, every day and you will be one the best contributing members of your team.

However, doing four hours of work every day is harder than it seems.

Proper work is work that includes no email, no Hacker News, no meetings, no dicking around. It means staying focussed for at least 45 minutes at a time. Four hours of work a day means that one day lost in meetings or on long lunches and foosball breaks means you have do eight hours the next one. Believe you me, eight hours of solid work is almost impossible. Four hours a day on average also means you should be aiming for five or six in order to prep for the day when you only get two.

However it also means you can be a huge contributor to your team while still having a fully rounded life. It means that you don’t need to post that self-indulgent “I’m burning out, please help me” post on HN. It means that simply by being consistent you can be valued and respected.

Software teams don’t slow down because people work four pure hours a day rather than seven (which is insanely hard to do consistently by the way). They slow down because people spend weeks with no direction, or because the louder and emptier vessels dedicate their paid time to discussing Google v. Facebook’s acquisition strategies over endless extended coffee breaks.

Just work. Doesn’t matter how incremental or banal your progress seems…

Do four pure hours of work each day, every day and you’ll be one of the best people on your team http://t.co/6JMyGvGuzl
— Peter Nixey (@peternixey) April 22, 2014

Write up the things you’ve done and share them with the team

However you document things, whether it’s through a mailing list like Copyin, a wiki or even just inline documentation in the code, you should take the time to explain your architectural approach and learnings to the rest of the team.

Have a tough time getting a fresh install of Postgres or ImageMagik to work? If you found it hard, the rest of your team will probably also find it hard so take a moment to throw down a few paragraphs telling them what you did and saving them your hassles.

One of the worst parts of programming is losing whole days to battling bugs or installation issues. If you take the time to document and distribute the way you found through that you could buy five times your wasted time back by forearming your colleagues.

Understand and appreciate the exquisite balance between too much testing and too little

Testing is a powerful tool. It allows you to set a baseline for the reliability of your releases and makes you less fearful to make them. The less fearful you are to release, the more you do so and the faster you improve.

However it’s also an overhead. Tests take time to write, time to run and even more time to maintain.

Think of testing like armour. The more of it you wear the harder it is to hurt you but the harder it is to fight too http://t.co/6JMyGvGuzl
— Peter Nixey (@peternixey) April 22, 2014

You become too heavy to move, too encumbered to flex your limbs, immobile. Too little of it and the first skid across a concrete floor is going to cut you open and leave you bleeding.

There is no intuitive answer to what the right amount of testing is. Some projects require more testing than others and testing is a whole new piece of expertise you need to learn in and of itself.

Take the time to understand what really needs tests and how to write good tests. Take the time to see when tests add value and what the least you need from them really is. Don’t be afraid to test but don’t be afraid not to test either. The right point is a balance; take time to explore where the equilibrium lies.

Make your team better

This is different to the other points in that it’s not something you can action so much as an indicator of whether your other actions are working.

Does your presence make your team better or worse? Does the quality of your code, your documentation and your technical skills help and improve those around you? Do you inspire and encourage your team-mates to become better developers? Or are you the one that causes the bugs, argues during stand-ups and who wastes hours of time discussing irrelevant architectural nuances because it helps cover the fact that you’ve done no actual work?

You should make your team better. There should always be at least one or two ways in which you make those people around you better and through which you help strengthen them. However, be aware that being “smart” alone is probably the least valuable and arguably most destructive dimension you can choose. In fact, if your chosen dimension doesn’t actually make you tired it’s probably not a valid one.

It’s not who you are on the inside that defines you

There is one, humbly brilliant line in Batman Begins which has always stayed with me. At some point in the film where he’s fooling around and acting up as a billionaire playboy, Christian Bale implores Katie Holmes to believe that he’s still a great guy on the inside. She answers simply: “it’s not who you are underneath, it’s what you do that defines you”.

Your contribution as a developer is defined not by the abstraction of how smart you are or how much you know. It’s not defined by the acronyms on your resume, the companies you’ve worked at or which college you went to. They hint at what you’re capable of but who you are is defined by what you do and how that changes the project and the people around you.

If you want to be good, apply yourself.

Comments on Hacker News

Amazon, the time has come to give you a key

peternixey2 — Wed, 29 Jan 2014 11:53:00 +0000

We’ve been beating about the bush here for years, Amazon but let’s be honest, it’s time for you to have a key. At first it was lunchtime dates at mine. We’d both be excited and both be there early. It was forward of me to invite you over so soon but what the hell, I was in the honeymoon haze! Then of course my job got more demanding and it was harder to sync our timings. So you very thoughtfully tried finding a spot in between us to meet, somewhere where you could make it easily and which I didn’t have any problem collecting from.

The problem was though it wasn’t always easy to get your gear home from those lockers and so even they didn’t work out that great. There was just too much stuff that I wanted to avoid hulking home and the locker just didn’t really help. Then finally we go to the late night booty calls. They weren’t ever really going to last. They were convenient, sure but hardly civilised. Now it’s got a bit weird with you telling me you’re going to send stuff to me by drone. I mean it’s a sweet gesture and everything and it’ll be cool to get stuff quickly but it feels a bit unnecessary. I know you love gadgets but there’s honestly an easier way.

Let’s get down to it, it’s time for you to have your own key. I’ve let complete strangers in to stay in my house and yet you, with whom I have had a relationship for the past 15 years I still won’t even let past the front door. So I think it’s time for us to move to the next stage. I want to give you a key and I want you to come and go as you please. It’ll make life so much easier. I’ll be able to order the things that I want to get but which aren’t currently worth the hassle - 12 bottles of Pellegrino, milk, orange juice - hell I’ll probably end up getting most of my groceries from you. I promise too that I’ll experiment with more stuff. I’m already hooked up to your Prime gig so if you’re willing to send it, I’m willing to try it. Any chance you could pick up returns as you drop stuff off too? That would be AMAZING. I would finally even start buying clothes from you then. Let me tell you, I live in a city and it takes me half an hour to get to the post office and that’s if it’s even open. Earning the money to buy gifts from you keeps me pretty busy and the Post Office and I have pretty separate shifts. I also don’t have a car so I’m not going to be buying anything big. I love the fact that you do returns but frankly if there’s even the faintest chance that anything needs returning then I’m going to avoid buying it. So, let’s move this relationship to the next level. I’ll cut you a key, you promise to look after it and we’ll take this up a notch. I’m game if you are? p.s. I realise you’re not going to carry around a bunch of keys large enough to make an Alcatraz jailer blanche. However I also have faith that you can figure out a neat lockbox or similar that I can install for our mutual convenience. Ta. Update Today Amazon released a service that unlocks your house. Comments on Hacker News

Like Climate Change, the Privacy battle begins as a marketing problem

peternixey2 — Wed, 06 Nov 2013 12:20:00 +0000

There are bad things happening with regard to our personal privacy right now. Many people don’t see anything wrong with them and many people feel no discomfort about them. Twenty years ago, the same was true of climate change. It took a long time to disseminate the dangers of climate change. It will also take a long time to disseminate the dangers of our privacy erosions.

We are taking part in an unavoidable and tragic pincer movement between the technology industry and our governments. We assume that privacy doesn’t matter because we implicitly assume we always have the choice to switch off, leave our phones behind and be private. Be private and offline or be online and observed.

Someday within our lifetimes, the technology industry will, with the best of intent, take that choice away. Someday soon, the proliferation of internet-enabled devices will flip the paradigm. We will be observed at all times, online at all times. We will have no privacy unless we pro-actively seek it out and we may lose the ability even to do that. At the very least we will be conspicuous by our absence.

Among those of us who see the problem looming there is a belief that we can reason and debate our way to making this issue go away. However we need to do far more than that. We have to change things such that people who don’t care and aren’t aware want it to go away too. We have to make them feel the danger. We have to market fear.

Try convincing someone that climate warming was real and that a gas-guzzling V12 engine was bad 20 years ago - good luck to you. Good luck trying to convince anyone to pay a premium for a battery powered car. It would never have happened.

It took 20 years of education, celebrity endorsements, films like “An Inconvenient Truth” and acres of data for people to finally develop an awareness (albeit generally a slightly retarded awareness) of what was happening with global warming. It wasn’t the data that made people want to change though - it was fear for what may come and desire for the now chic options which might avoid it - the Prius’, Teslas and carbon-neutral flying.

We face exactly the same problem with privacy. The NSA knows the implications and a subsection of the public knows the implications but that subsection is tiny. The vast majority of people don’t understand the implications but more importantly they don’t feel there’s a problem. Even if we convince them there are implications they won’t do anything until they *feel* them. That is something different.

No government is going to change anything until they feel that there is something wrong. Every sale starts with emotion and only ends with logic. we’re trying to tackle this problem the wrong way around - by starting with logic. We need to make politicians and the public feel the fear, feel the discomfort and only then offer them the logic to rationalise that fear and solve the problem.

If Google and Yahoo and Facebook are really serious about wanting to protect our privacy they could do so by marketing the implications of what happens when it goes away. They could to fund films, documentaries and even advertising. For years our governments have shamelessly marketed themselves into power using fear. Now we need to market our rights using the same tools back.

When the politicians and the public start feeling the consequences they will start wanting to act. They may never understand fully why they do that, the important thing is just that they do. You can’t always tell a child that something is dangerous, you have to show them it’s dangerous. You have to scare them.

How Dropbox could beat Apple in Photos

peternixey2 — Thu, 10 Oct 2013 10:47:00 +0100

After my last post on photo management it became obvious that I was far from alone in my concerns about iOS photo management. The article hit a nerve and thousands of people retweeted it and even John Gruber and MG Siegler linked to it.

The problem clearly affects a lot of people. The question is what to do about it. Photos have been updated in iOS7 but few of the real problems seem to have been addressed.

The problems with iOS photo management today

1. No ability to organise photos across devices
iOS still extremely ineffective tool for organising images across devices. While iOS7 has introduced “moments” which seem to cluster photos by geography and time, there’s still no way to edit either the naming of the moments or even the clustering of them. Not only that but the moments are (so far) still tied to each individual device.

2. No ability to access photos cross-devices
Without doing a three-way sync with a Mac (which you may not even own) it’s more or less impossible to get a clear set of organised and curated photos natively synced across devices. Photostreams are unfortunately a mess and so no native way to settle back with your iPad and put together an album which you might later access from your Mac or iPhone. This is a tremendous waste.

3. Not enough value to make it worth paying for backup
iOS does offer a background backup service for your photos. This is helpful and the entry-level pricing of $20/year is much more manageable than Dropbox’s $120/year. However, while an investment in Dropbox gives you sync-space for everything, Apple’s is far more limited and basically won’t be used for anything more than photos. Dropbox offers you far more flexibility with the storage you purchase.

Dropbox should solve the problem
This space is hot. Photo backup is almost certainly the key to getting consumers to pay for backup and that is a very large market. After my original post, many representatives from startups and some very large companies got in touch to suggest I try their photo products. A number were good but after trying many of them I realised that Dropbox is the company I want to solve this.

I want this because at its core, the problem fundamentally boils down to syncing files across my computers. That’s going to cost me money and bandwidth and will cost my computer processor time and memory. I already pay Dropbox to do this and I don’t want to add the complexity of another service running in parallel.

Dropbox is also in a great strategic position to do this. Many people are loyal to iOS or Android but many more (perhaps the majority) are not. Android’s catching up with iOS fast and against Apple, Dropbox is in a strong position to nail this space because it’s one of the few companies with a strong foothold across both platforms. If you’re not 100% sure that you’re sticking with iOS you definitely won’t want to commit to Apple for long-term backup.

Unfortunately though, while Dropbox has the sync part down, it offers almost nothing else. Here’s what I think it needs to start doing in order to tackle this:

1. Provide a cross-platform Photo Management API
Cross-platform today means much more than it did ten years back. However, to deliver on photo management, Dropbox needs a photo management tool and that means they need one on every platform. I think the complexity of the project means that the key to success is probably not focussing on interface but instead focussing on building a superb-quality, cross-platform API and datastore.

I’d build a common, core-database and API and then completely separate the challenge of building applications for iOS, Mac, Android and Windows. Running a cross-platform interface project would be a nightmare whereas starting with an agreed-on database, file-structure and editing API could at least decouple the interface programmes. It would also let developers build and sell management apps for the platform themselves.

Minimum functionality for such a synced API would be
- delete photos
- organise photos into albums
- leave scope for smarter auto-album-organisation in the future
- simple editing (red-eye / crop / auto-enhance / filters)
- store edits with original file and only ever present one copy to the user to organise

Building a set of native clients is no small task and if I were running that project I’d want to know how much overlap there was with applications which are already on the market. Companies like Loom are surging ahead with great functionality and if you could buy them and retrofit their interfaces to a common set of standards then you could shortcut a lot of dev time.

2. To endeavour to become the native Camera Client for the user
The more frequently the user interacts with their photo library, the more time they will invest in it, the better it will be and the more they will value it.

One way to increase interaction frequency is to be the native camera app. This doesn’t need any fancy functionality but should offer at least parity with the existing native app. On iOS you you unfortunately can’t rely on being *the* native camera app because fastest way to access the camera is through the lock-screen and only Apple has access to that.

3. Remove the confusion around multiple copies of photos
This seems small but is fundamentally a huge problem. People need to stop having multiple copies of photos. If you have multiple copies it means you don’t know which one to delete or which one to edit. Creating copies of photos in a photostream which are then edited or deleted separately from the original photo is incredibly confusing. All of this is a mess and a pain.

Dropbox needs to figure out one way or another how to make sure that users only have one copy of each photo in Dropbox and no others in the photostream or on the camera roll.

4. To make their pricing more accessible
Dropbox’s cheapest plan is $10/month which is a lot to ask from someone who’s never paid for storage before. However, and at least on iOS, Apple has kindly provided a forcing function to make users consider paying.

Dropbox’s biggest friend right now is the “Your iOS storage is almost full” notification. Users get this when they run out of their initial 5Gb on iOS and then have to pay to upgrade or start deleting photos. Left to their own devices most users will never pay for things and many people will just delete photos until the warning goes away. If Dropbox could do some jujitsu to figure out when a user hits their limit then they could message the user at the same point and undercut Apple.

Offer dual-tier storage
Data’s not cheap to store so undercutting Apple wouldn’t be easy but one way that Dropbox could do compete is by leveraging cold storage. Dropbox can offer to backup high-resolution photos securely but without immediate retrieval (i.e. by using Amazon Glacier or similar). That way they could offer peace of mind while charging a fifth of the price. Users could buy peace of mind cheaply and then pay for access later on. This could also be a way to segment the market and offer plans which are nominally high-storage without cannibalising existing higher plan subscribers.

Trade storage for credit card details
One of Dropbox’s biggest problems must be getting people over the penny-barrier and convincing them to open a new line of expenditure (storage). Making the ramp more shallow would help and giving them something for just entering credit card details (1Gb storage?) would make it much easier to get involved. Paying for backup is a big thing for a lot of people and making that easier should be a big priority.

Young people are taking a lot of photos but aren’t inclined to pay for things (especially since many of them don’t have jobs) but within only a few years those people will become mothers and fathers with children and photos of those children that they don’t want to lose. The more Dropbox can get them over the hurdle of credit-card input and crossing the-penny-barrier before that time comes, the more likely they are to start paying to save their family memories.

5. To be fast, transparent and reliable
I use Dropbox to backup my photos and it currently has 5 photo (or video?) files which it refuses to sync successfully. I don’t know what they are, I don’t know why they won’t sync and I don’t know how to get them to sync. Because they haven’t completed I don’t trust that any of the library has completed and I’m not ready to delete the old ones on the camera roll. Every time I open the Dropbox app it takes over a minute for the photos section to load and it not infrequently crashes.

Dropbox also splices all photos stored anywhere in the Dropbox folder into the photos view of the application. This is both unexpected and undesirable. I don’t want drinking trips spliced in with family photos. If photos from a stag trips on a Saturday night are going to appear next to photos from a baby shower the next day then I’m never going to show people those baby photos because I won’t want them scrolling through the stag photos. The whole thing is club-handed and badly thought through.

Dropbox can’t afford this sort of confusion. The company succeeded with files because it did everything quickly, reliably and responsibly. Doing this right is no small challenge but a company which does will be treasured by its users. Dropbox needs to constantly go the extra mile in UX to show what’s happening and to give users the agency to fix problems themselves.

Why is this a problem worth solving?
The battle to win the world’s photo management market is a huge one. It’s a huge amount of work but it comes with huge spoils. The number of photos people are taking is growing exponentially. The devices on which that is happening are increasingly connected to the internet and Dropbox is already part of the file system on most of those devices. People want photos to be private by default and they want something then can rely on. Dropbox has already proved itself to be reliable and unlike Google Plus, Facebook and Flickr, it’s private by default. Dropbox is the heir apparent.

The cost of storage continues to fall while the number of photos and videos recorded continues to rise. The arbitrage opportunities are almost as good as they will ever be. In many ways I wish that Apple would solve this but that doesn’t look like it’s happening and for all of its lethargy in getting going, Dropbox is the next best bet.

Apple's fingerprint sensor may be the biggest leap forward in payments since the Amazon Account

peternixey2 — Tue, 10 Sep 2013 21:38:00 +0100

During today’s keynote, Tim Cook mentioned, almost in passing, that you could log into the iTunes store using the fingerprint sensor.

This statement may turn out to have way more significance than its low-key delivery would suggest. It took me a moment to realise it but the fingerprint sensor is almost certainly not about securing your device. The fingerprint sensor is about securing your account. The fingerprint sensor is about payments, initially to Apple and then maybe subsequently elsewhere. The fingerprint sensor may be Apple’s mobile answer to Amazon’s web-bound One-Click.

For every app, music and in-app purchase made through an iOS device there is at least one other that wasn’t made because someone couldn’t be bothered to type in their password, got it wrong or just didn’t know it. Amazon once measured a discernible difference in checkout rates from page loading increases of only 1/100th of a second. Apple has to request a password. That password has to secure the phone against chargebacks due to theft, purchases made by small children or just a trouble-making friend pinching your phone and playing with it. The only answer to those chargebacks today is to demand users to continually re-enter their passwords.

Perhaps even more problematic for Apple is the proportion of their customer base who don’t even know their passwords. A significant proportion of iOS users won’t be able to tell you their password and may not even have a credit card associated with it. Apple must have swathes of older, tech-challenged or simply disinterested customers who never buy any video, music or apps. Those customers are lost revenue for the iTunes store in the short term and are far more vulnerable to churning over to Android in the long term.

Because it’s not the just the revenue from apps that passwords cost Apple. Apps are what make the platform useful, apps are what tie you to your OS and many of the best ones need to be purchased. If you don’t buy apps the platform is significantly less useful to you, you’re far less loyal and you’re far more likely to be swayed by Android. Apps are Apple’s platform lock-in.

I’m guessing that this new scanner won’t just be a piece of hardware Apple ships and forgets about. I’m guessing that Apple will integrate their efforts around the fingerprint and will encourage you to setup your fingerprint and enter your credit card in the Apple store when you buy a new device. I would. They will do everything they can to encourage you to associate your fingerprint with your credit card and free you to one-scan purchase. I’m also guessing that despite its more homebound nature we’ll see that fingerprint sensor very quickly on the iPad too. The iPad is a perfect shopping tool and one-scan shopping would make that even more true.

The fingerprint sensor is way too much technology just to make it easier for you to get past your lock screen. As Tim Cook said, many people don’t even setup a PIN. I think the fingerprint sensor promises to be a far more strategic tool than simply a souped-up login. What the fingerprint sensor may actually deliver is the biggest improvement in frictionless payments since the Amazon account.

Apple has to make big bets to move the dial now and payments is one of those that many people have spoken about. Many people were waiting for Apple to announce NFC and jump into the payments space but I think they may be even cleverer than that. Payments would be a huge new revenue stream for them but easy authentication and chargeback avoidance must have been a large barrier to offering that. If the fingerprint recognition works a well as advertised, that barrier may just have fallen away.

Comments on Hacker News >

Things I've Learned About How to Build Good Product

peternixey2 — Wed, 04 Sep 2013 15:48:00 +0100

These are the slides from the talk Taavet Hinkrikus and I gave yesterday at the O2 for Campus week and Wayra.

The talk is about how to build good quality product quickly in highly uncertain situations. It’s about building product in a pre-product-market-fit startup and I like to think that there’s something for everyone (over the age of 29) in there.

If you, like me, lament the fact that Craig David and XKCD sex scenes have have never before met in a presentation about product then you’re going to LOVE slides #90-99 (also I hope you at least remember Craig David unlike most of the blank-faced audience I was talking to).

If you’re wondering what the relevance of the Ariel Atom and a kitted-up Peugeot 206 (#106-110) is it’s this. One looks like a piece of scaffolding that fell on a go-cart but goes like s**t of a shovel while the other looks, well… crap but it’s owner clearly spend a lot of time on “design” while paying no attention to the fact that there’s not a lot of point in it as a car. This is a metaphor.

Enjoy, debate and if you chose to upvote this at Hacker News, well then let me tip my hat to you as you’re a gent sir (or mademoiselle). Gracias.

Comments on Hacker News >

How to build product campus week from Peter Nixey

Using Sidekiq and OpenRedis on Heroku

peternixey2 — Mon, 02 Sep 2013 17:03:00 +0100

I recently switched from using DelayedJob to Sidekiq for processing my background tasks. Sidekiq’s super-powerful for jobs that have a lot of latency (like external API calls) since it parallelises them in threads and runs 25 (by default) at a time. This can literally divide the number of boxes you need to run things by ten.

However it took me a little while to debug some stuff in order to get it running well on Heroku. I hadn’t been using Redis before and so I had a few moving parts to sort out. I kept getting the error:

sidekiq Redis::CannotConnectError (Error connecting to Redis on localhost)

The problem was that I hadn’t told Sidekiq how to connect to Redis. In case you’re having the same issue, this is how I fixed things.

1. Setup a Sidekiq initializer file

As per https://github.com/mperham/sidekiq/wiki/Advanced-Options you should add a Sidekiq initializer file which will look something like this:

————

# /config/initializers/sidekiq.rb

redis_url = Rails.env.development? ? ‘redis://localhost:6379/0’ : ENV['REDIS_PROVIDER’]

Sidekiq.configure_server do |config|
config.redis = { :url => redis_url, :namespace => 'twistilled’ }
end

Sidekiq.configure_client do |config|
config.redis = { :url => redis_url, :namespace => 'twistilled’ }
end

————
NB I haven’t figured out and can’t bring myself to figure out how to format code correctly in tumblr so if you copy and paste my ocde you’ll need to make sure that single-quotes and double quotes come through with the correct characters on your machine.

2. Add your OpenRedis URL to Heroku as an env variable:

————
heroku config:set REDIS_PROVIDER=your_redis_url_from_open_redis
————

3. Check things are working via the Sidekiq console

You can monitor the status of the system by mounting the very pretty Sidekiq console in your routes file (NB you should password protect this):

————
# routes.rb
require 'sidekiq/web’
mount Sidekiq::Web, at: ’/sidekiq’
————
view this from yoursite.com/sidekiq

EDIT

This may not all be necessary. See this conversation on Twitter with Mike Perham. Unfortunately (possibly due to something I set incorrectly) I couldn’t get this technique to work but you may do:

https://twitter.com/peternixey/status/374563696296853505

Our very real liability as Twitter app developers

peternixey2 — Mon, 19 Aug 2013 14:03:00 +0100

Last week Carl Icahn sent out a tweet that raised the market cap of Apple by $17Bn. Carl was under no illusions as to the significance of his disclosure, and filed with the SEC before doing so to state that he may use Twitter to release information he considered to be material.

The ability of high-profile Twitter accounts to move markets is now very real and doing so nefariously is not unprecedented. In April of this year crackers got hold of the Associated Press Twitter account and wiped an estimated $135Bn off the S&P 500 Index by tweeting that explosions at the White House had injured president Obama.

Being implicated in such events this has huge consequences. A friend’s company recently suffered a data leak and afterwards he told me that it was one of the worst weeks of his life with an office full of lawyers and FBI agents. He said “I hope you never have to go through this”. That happened as a result of leaking their own (encrypted) passwords. If you were a developer implicated in the compromise of a high-profile Twitter account which broadcast market-moving material then I can only assume things would be many times worse. Such an eventuality may be closer at hand than you imagine.

If you ask for write-permission for Twitter accounts then you have access to those accounts. And if someone gets access to your server or database then they may do too.

In order to get hold of your users’ accounts a cracker needs four things:
- your users’ oauth tokens and secrets
- your application’s consumer token and secret.

The first two aren’t of any use on their own as any API call still needs your application’s consumer token and secret. If, however, the hacker has access to your users’ tokens and your consumer tokens then they’ve got the keys to the kingdom.

You should be absolutely 100% certain that the four of these things are never available to a cracker. The most significant and protectable of these is your application’s consumer secret, however you should also think carefully about how and where someone might get hold of the other three. Best practices for protecting these will vary depending which platform you’re on.

We’re going to see a rise in Twitter attacks over the coming years. It’s now such an influential news source that getting into users’ accounts is only going to become more attractive. The prospect of honeypot apps or developers paid by financiers to move markets becomes ever more likely. Finance aside, the power of Twitter to incite civil action or even violence is very real and would undoubtedly have huge implications for a developer who inadvertently enabled such activity.

As developers we should think carefully about the liability we take on when we request write-permissions for an account on Twitter.

However I think that Twitter also has a responsibility to educate and protect its users more than it currently does. Users with large followings should be warned about the ways their account can be mis-used by connected apps. They should also be encouraged to switch their account to a “secure” mode where it can only connect to apps which have been whitelisted or even perhaps a super-secure mode which would disallow app-connections altogether. Most people have very little idea of the implications of connecting to a Twitter application. Even if did though and they they knew they could trust it, they can’t possibly anticipate how securely the application’s been coded.

Over time we will undoubtedly see more clarity in the law and in how liability will be allocated across such a chain of events. Unfortunately it’s going to be a precedential case and a scapegoat developer which will forge this. When this does happen we will discover how much responsibility will fall at the app-developer’s doorstep for not properly securing themselves and at Twitter’s for not properly informing their users of the risks.

As more and more influential people join Twitter, such attacks will inevitably become more frequent. In the meantime, as application developers, we should be careful with what liability we chose to take on and how we protect ourselves and our users from it.

Comments on Hacker News

"Instead of cures for cancer we got Angry Birds"

peternixey2 — Tue, 30 Jul 2013 11:26:00 +0100

“The Valley’s brightest minds once invented things of immense significance like the first PC. But then came the internet and the pursuit of big ideas was eclipsed by a scramble for quick profits. The money pumped into hard technological problems plunged while interest in iPhone apps soared. The result? Instead of cures for cancer we got Angry Birds”.

So concluded a recent article in the Sunday Times. “Does it really matter”, “you could working things that could save lives, why worry about dry cleaning?”. Casual observers love to glance through the office windows of entrepreneurs and wonder “if there’s so much money to be made in entrepreneurship, why don’t these folks do something that really matters”.

I can perhaps understand where they’re coming from. One of my brightest friends is looking to start a new idea in advertising or property. I know that he’ll do very well in whatever he choses but it makes my heart sink to think of his talents being used to optimise advertising. I don’t expect him to stop the spread of malaria but he’s a source of creative energy in the world and it would be nice to see him use it for something that I might at least use.

Asking him or any other entrepreneur why they solved one problem and not another is like asking a river why it doesn’t splash out and irrigate the fields above it. “Since you’ve got so much water, why not wet my crops rather than just deepening the plunge pool under the waterfall?”. The question is moot. Water flows downhill: down a potential gradient. Like water, entrepreneurship also follows a potential gradient. Water depends on a height gradient, entrepreneurship on a value gradient. The greater the gradient, the faster they move and asking why things might be different is as pointless as arguing with water.

Entrepreneurs follow those gradients for good reasons too. While the Sunday Times may photograph Brian Chesky hanging out in AirBnB-central they don’t photograph the entrepreneur who had to give up his company and leave penniless to look after his dying sister’s family. They don’t photograph the hundreds of young hackers holed up for years in Palo Alto with nothing to show for it. They don’t photograph the founders who watched their company fall apart as they stood locked in a legal Mexican standoff. If they did their question might change from “why do you not cure cancer” to: “why do you do this stuff at all?”. Entrepreneurs follow potential gradients because their business is a risky business.

I think the “does it really matter” philosophy comes from two misapprehensions. The first is the assumption that markets are fungible and the second is a lack of ability to distinguish small probabilities.

When you assume markets are fungible - that one can be tackled as easily as the next - you inevitably ask whether “disrupting the dry-cleaning market” really matters when the alternative is “feeding Africa”. These aren’t adjacent problems though, they’re literally and figuratively continents apart. There are already entrepreneurs tackling both problems but they are entrepreneurs with very different knowledge sets. Getting frustrated with software entrepreneurs failing to feed Africa is like getting cross with Norman Borlaug for not doing a dwarf wheat iPhone app. These are different entrepreneurs with different skills and different available markets.

When you have no way to distinguish small probabilities then all long-shots look the same. Two “seemingly impossible” ideas may still be magnitudes apart in probability. As incredibly small as it is, the chance of successfully building a new car manufacturer is still millions of times higher than that of curing cancer. To the average person both ideas may seem vanishingly small but good entrepreneurs work with a microscope. They can magnify their field up so large that they know every nook of it. What looked like two small specks to the untrained eye looks completely different to the entrepreneur. They see one as a cell with all of its mitochondrial energy-producing goodness while the other, a million times smaller still, remains as mysterious as it was without the microscope.

Finally, it’s worth pointing out that entrepreneurship isn’t a salaried job-rotation or an credit-option on an MBA. You don’t chose the option you fancy most and then roll on to a different one three months later. Being an entrepreneur is a nail-biting, ration-sapping, wind-bitten, many-year, unsupported journey into the unknown. Asking an entrepreneur why they took one route and not another is like tweeting to a climber on K2 to ask them why they didn’t take the harder route. Ask away but if you think it should be climbed then you should buckle up and climb it.

Comments on HN

Five techniques that measurably improved our customer development

peternixey2 — Mon, 15 Jul 2013 17:05:00 +0100

When we first started building Copyin we had a problem. We found it incredibly useful but our early users felt differently. We loved that it created a knowledgebase out of our email. The problem was that we couldn’t communicate that benefit to our customers. People were receptive to the problem but (at that stage) not the product.

So we found ourselves in a quandary. We had a product which was valuable to us but not to the people we’d so far shown it to. So did we have a product or a market problem? We didn’t have enough data to know. After all, it wasn’t like we were the only product in our space those people didn’t use - almost none of them used Salesforce or Yammer and they were both successful nonetheless. Was our sample size too small or our product off-mark?

In order to answer this we needed to speak to more people. We knew we could get them from a public launch but we didn’t yet know who we were launching to. We felt it would be a waste to launch while still so far off product-market fit. However we still needed to speak to more people and to different people and we needed to do so quickly.

1. We created an inbound customer development pipeline using our blogs

The first thing we needed was more people. For that we turned to our blogs. Both Rob and I had already had a fair amount of success blogging so we decided to experiment with recruiting people directly from blog posts. We built a small signup form, cached it to withstand traffic and embedded it in the bottom of each post.

To our delight, the form worked. About 1% of people who saw it signed up and we immediately increased both the reach and diversity of people we were interviewing. We had enquiries from everyone from CTOs of publicly listed technology companies to administrators of NBA teams and mountain rescue societies. We did all of this without even altering what we blogged about. If we’d written about Copyin or its problem space specifically I’m sure we’d have converted even higher.

2. We immediately followed up on new registrations to arrange interviews

Our goal was to get interviews not signups so once people had signed up we immediately sent them an email thanking them for their registration and inviting them to speak to us.

At first we worded this invitation email in a very softly, softly, manner: Hi, it’s Peter from Copyin. If you have a moment we’d love to chat to you. We can speak to you when it’s convenient, please do get in touch.

Nobody responded to these though so we changed the text to be much more exclusive with limited availability:

We’re prioritising customers with real pains in this area. If this is you then please get in touch and we’ll book you in as soon as we get an opening. If it’s not then please accept our apologies but we’ll get to you when we can

The latter converted very effectively and about 10% of registrations emailed us back to tell us more about their particular needs. Almost everyone who emailed us was happy to do a phone conversation and we’d spend anywhere from ten minutes to an hour speaking to them about how they were currently solving the problems that Copyin addressed.

3. We stopped pitching and started listening

When we first started customer development we made a massive mistake. Instead of listening to a customer’s problems we would instead pitch them our solution What we should have been doing was asking people what their issues were and listening to how we might solve them. What we actually did was wax lyrical about the product and debate with them on whether it really could solve their problems (at the time it couldn’t).

Customer development is a very different process to sales though. Sales is about helping your customer to understand the product. Customer development is about helping the product to understand your customer. Don’t try and sell during the initial exploration.

4. We made sure that the whole team was a part of it

After each interview we’d sent both the transcript and the summary to the the rest of the team using Copyin. Disseminating the research is tremendously important. The temptation as CEO is to yank the product tiller after each and every interview. This leaves the team feeling bewildered as to why the thing they were working so hard on is now so unimportant. Their natural reaction is to stop caring so much in case what they’re passionately working on suddenly gets binned.

Obsessively sharing customer research has three huge benefits. The first is that when you do need to move the tiller everyone already understands why. The second is that it encourages you to discuss product as a team and gives everyone a vested interest. The last one is that you have a written record of what actually happened.

If you don’t give the team access to customers it’s easy to dismiss their opinions as being uninformed. This can cause decisions to be over-volatile and is bad for morale. If they do have the data then they can not only offer valuable opinion but also become a powerful protection against CEO tiller-yanking and over-correction.

5. We used our embedded signup form to test new hypotheses

As you do your customer development you will start to form new hypotheses about what the customers actually want and what their problems actually are. It’s incredibly useful to test these and to see whether they’re correct or just a result of your last interview.

We were able to do this by incorporating three very simple benefits from Copyin back into the original enquiry form and cycled through various features that tested our hypotheses:

- turbo charged mailing lists to better connect your team
- Search-assist to make sure you never answer the same question twice
- Tag, file and edit the email threads actually worth keeping

and

- Connect to the expertise in your team
- Capture your team’s knowledge
- Know what’s happening

By seeing which phrases people responded to we began to see which things they cared about (and which ones they were prepared to pay for). These phrases also helped drive what they put in the last (most helpful) box which asked them what they would use Copyin for:

We got a variety of answers to this. Early on they were vague and sent by people who (upon interviewing) often turned out to have no budget. Over time and as we improved our positioning we were able to select better and better for people with real budget and more tangible problems. What people answered to “What would you use Copyin for?”

We’ve got a vastly growing team, with a huge email load. Streamlining this process would be amazing.

Need to track conversations multiple people are having on multiple topics over multiple channels

Populating Knowledge base with relevant content about processes and services.

More Cow Bell

(wat?)

The data was statistically insignificant but it was nonetheless very helpful in understanding which terms appealed to which people (and to which budgets).

Conclusion

It’s very easy for customer development to fall by the wayside and to think that it will “just happen”. It’s not easy to do though and involves being humbly wrong many times in succession. It requires all the pro-active outreach and rejection of sales without any of the highs from actually selling anything.

Done properly though it is incredibly powerful and painful only because it compresses a year of head-in-the-sand learnings into a few short weeks. That much medicine is never easy to swallow.

We found that with the funnel in place the rest followed very naturally. For us, heavy investment in customer development let us go from a product which nobody really understood to one which people now get in a single sentence (

create your company knowledgebase from your everyday email

) and really want to use.

Discussion on Hacker News >