In search of the viral loop

Cross-posted from Zolo Labs.

Just finished reading Viral Loop. As we think about the distribution side of things for Zolodeck, I figured it couldn’t hurt to read about how a bunch of companies achieved massive scale.

It’s a good read… and certainly describes how things were done at companies like Hotmail, Twitter, Facebook, Hot Or Not (remember?), Bebo (remember?), MySpace (remember?), eBay, Flickr, PayPal, and even Tupperware (yeah, really).

It isn’t, however, a book of recipes. I didn’t really expect a book to be able to just tell me the 10 things I can do to fix distribution, I guess, and on that count the book was merely describing how awesome it is when you do achieve massive scale. Not how to get it.

Still, a very decent read, and did trigger a few thoughts for what one can do to address this. A lot of people in the startup space know this already, but it’s been sinking in for me more and more over the past few months: distribution is the more important of the two key things a startup needs to solve (the other being product/market fit, or product in general). And also that distribution is the harder of the two problems, and more than product, it is distribution that will make or break the company.

As I said, we’re thinking a lot about this for Zolodeck… and since this is so important, we’re erring on the side of over-measuring things to ensure we can keep a pulse on what the distribution story is looking like. What else can one do at such an early stage?

Make something people want

Cross-posted from Zolo Labs.

I’ve been reading Paul Graham’s essays for a long time: since 2001, when an old friend introduced them to me. I was excited by the way he writes about startups and what startups can accomplish. In my head, startups are like the Rebel Alliance, with the odds heavily stacked against them, and they battle the various Death Star corporations for a slice of the business, to institute a smarter way of doing things.

I was also heavily influenced by his articles on Lisp, particularly this one. It’s why I started playing with various Lisps, and why I was so excited by Clojure, and why I wholeheartedly embraced it.

But this post isn’t about technology. It’s about the Rebel Alliance. It’s about two guys in a makeshift office, in the proverbial garage somewhere. Startup statistics can be quite depressing, with 19 of every 20 startups doomed to failure. With such a low rate of success, how do the successful ones do it?

I remember reading this article by Paul Graham, and thinking it makes sense. I remember it making sense in a very superficial, non-committal sort of way. The core of the statement: “Make something people want” seemed perfectly obvious to me. How could you succeed if you didn’t make something people wanted? Duh. Right?

I’ve been spending a lot of time thinking about Zolodeck, the depth of this idea is actually hitting me quite hard. There are two parts of any tech startup: the product side, and the distribution side. The product side is about finding the product/market fit, about making sure the experience is right, and that what you charge for the product is more than what it costs to make. The distribution side is about customer acquisition. Obviously, there’s interplay between the two sides.

“Make something people want” is a simple recipe for success. It seems to distill everything the Lean movement talks about into a single sentence: is your startup making something people want? Everything else is details (of course, the devil is in the details, and you need the details to succeed). In the end, you have to collect and collate the metrics that will point you to what it is that people want, and that will tell you how and what your startup should be doing. But the overarching guiding principle is very sound: make something people want.

And yet, a lot of startups fail because ultimately they don’t end up building something that enough people find value in. Or perhaps at a cost that was lesser than what they could charge for it.  Making something people want doesn’t mean that if you build something incredibly powerful and useful, but at a gargantuan price, you’ll succeed. The something you build for people needs to solve an equation that involves cost, price, scale, and utility.

So back to the two guys in their garage. If you’re a tiny startup (in reality or in spirit), you can greatly increase your chances of success by using this mantra as a guiding light: make something people want. And make use of Lean metrics to see if you’re trending towards a success or failure. I really do believe that if done right (pick the right metrics, and make adjustments based on what they say), a startup can succeed. And given the stats on startups, this is a bold claim.

I plan to share our Lean metrics dashboard and overall progress as we continue to work on Zolodeck. I think of it like a public experiment. Hopefully, we’ll discover something of value, and others can benefit too! Go Rebel Alliance!

Facebook and the MMVP

Cross-posted to Zolo Labs.

I didn’t realize just how true my previous post about the minimum MVP might end up being. When we first conceived of Zolodeck, we figured we’d build it the Lean Way. In that process, we came up with an MVP – and this included support for LinkedIn, Twitter, email inboxes (GMail, etc), and possibly, Facebook.

Now, however, given our time constraints, it looks like our first (pre) alpha (is that even a real term?) users are going to start with Facebook only! Every time we started planning our initial alpha public release, our burn-down projection would show something horrendously far into the future. So we kept cutting back, and we think we have something now. Something that we’d want to use ourselves.
I’d have never believed myself if I’d told me I’d launch with just Facebook. But in some ways, this narrowed scope is actually better (apart from being doable in a reasonable amount of time). It will give us a slice of functionality to test, all the way through one end to the other. Our other sources of data (email, LinkedIn, Twitter, etc) are extremely valuable, but they can easily be added later. Just having Facebook means that we can focus on the value-add of our app, rather than just having data from all over.
In any case, we’ll see what our users will say 🙂  

Love and the minimum MVP

Cross-posted to Zolo Labs.

The start of a new project is always exciting… there’s the anticipation of awesomeness that can make one giddy 🙂 It’s the potential of the idea, the opportunity of the clean slate, the possibility of applying all learnings to date, and the hope of doing things right

Of course, a business is more than just the product. Somewhere, there’s got to be money involved. And for that, there have to be people who get enough value that they actually pay you. And that you can take in more than you spend to provide the service… 

Here’s the thing, though: if your product is in a “new” space (hasn’t everything that could be invented, already been invented?), then how do you know if you’re building something anyone cares about? This is where the minimum viable product (the much talked about MVP) comes in: the idea is that you build just enough for your early users to try out the product and give you critical feedback that would help you understand the market and its needs. Obviously, these early adopters are not the majority, so the data gathered needs to be adjusted accordingly.

So far, so good – the MVP approach looks really good for new products. For Zolodeck, for instance, we came up with what we thought was a fairly thinly sliced product. What we didn’t count on was that since Zolodeck is still a nights and weekends project (a labor of love, if you will), we don’t quite have enough time to build the MVP of our dreams. So we’re now building a minimum MVP. We’re calling it, wait for it… an MMVP. 

Given that we’re so resource constrained right now, Lean ideas really help. And the MMVP takes this to an extreme – we have to choose just those 1-2 things (maybe just 1 thing) that are the most important to test right now. We really need to think through prioritization of our feature road-map, and decide what to build next. The prioritization needs to take into account everything we can think of – product/market fit, business and technical risks, and so on.

We’ll post updates here as we make progress. For now, we’re hoping to get something into the hands of our first dozen users in the next couple of weeks. Stay tuned!

Designer-driven vs. metrics-driven product design

Cross-posted to Zolo Labs.

An interesting question cropped up over dinner the other night – does metrics-driven design have any place in the world of designer-driven product design? For instance, Apple is famous for not using focus groups and so on, and instead relies on their own processes and practices to develop their amazing products.

I’m a huge believer in Lean methods for developing products and building a business (I’ve written about this before, and spoken about it as well). I’m also a huge Apple fan-boy (yes, I wept when Jobs passed). And obviously, Apple does a lot of things right when it comes to developing products.

So how do these two ways of driving product design mesh with each other?

My point of view is that they’re not mutually exclusive. While there’s no substitute for vision (and thereby designer-driven product creation), metrics can serve as an excellent sanity check. They’re really guard-rails, guide-posts, safety-net, compass, or whatever analogy you want to use. They can be especially useful when the product is in a “new category” and where there may not be established usage patterns or user behaviors to draw from.

If you buy into the “iterations are awesome, fail-fast, learn-improve-repeat” process, then you really can’t do it without metrics. And, of course, you need the right metrics, but that can be a post for another day.

Adopting lean software development: What is a user story?

I recently got an email from a reader (Dmitry Lobanov) who had some questions about the process stuff I’ve written about here. With his permission, I’ve reproduced the contents of his email and have responded to his queries. It may help other folks that are in early stages of adopting lean/agile methods –

Hello Amit. You keep interesting blog with a lot of useful information about project management. To my opinion the most attractive idea in your blog is user stories decoupling.

Let me tell how I found it interesting and then I’ll ask a few questions, Ok?

In our project we use scrum with some XP techniques. I found link to your blog in an overview of Mingle at Thoughtworks website. While reading I found your idea of decoupling stories into 2 story points tasks very interesting. And I think, that it makes sense. We tried to compare two approaches (yours and card poker) while estimating amount of time required for 1 specific user story. Well, it is not 100% your approach in fact, because we still tried to use estimation and ideal days, but we took your idea concerning 2 story points tasks. But we are not ready to forget about estimation yet 🙂

First we estimated using card poker, and then repeated estimation using your approach. And we found the following advantages of your approach:
– your approach gave us complicated tree of concrete task. That means that we could just take them and start working on this user story, we know what and how should be done. In other words we have got a plan! Card poker didn’t force us to decouple user story into atomic tasks and just gave us list of generalized tasks (which themselves can be user stories).
– card poker estimation gave us some number of story points (we used ideal days according to scrum guidelines), let it be X ideal days. And then we used your approach for estimation: number of atomic tasks multiplied by 2 story points (we still use ideal days 🙂 ), let it be Y ideal days. And we have been amazed, that Y was 10 times greater than X! 10 times! That’s too much.

This experiment shows us that standard estimation lacks of accuracy a lot… well, we suspected it, but only after experiment we saw it clearly. And using card poker (i.e. bad decoupling) we constantly have problems with developers got stuck in development process, and as a result they do 5-days task for 2 weeks or even more. We have one user story, which had been estimated as 8 days, but two developers work on it for 2 sprints already. It’s no good at all.
So in the near sprint we’ll try decoupling user stories into 2 story points tasks and watch the result.

I have a couple of questions about decoupling and sprint planning, and it would be nice if you provide your point of view concerning them.

In your post about requirements management ( you touched only initial planing. But what to do with bugs and technical tasks? I’ll explain. Look, our project has been in development for 2 years, we develop payment acceptance system. And our system has been in use for a bit less than 2 years (it took approximately 3 moths to issue first release). So it changes constantly, we issue new release every 2-3 weeks. But when the development started, team suffers a lot from a lack of project management experience. I came to project few months ago (I’m not a project manager, just developer, who wants to improve project). Now situation seems to improve. But we have a LOT of bugs. As you understand, these bugs can’t be attached to specific user story, moreover we hadn’t user stories before, in fact we introduced scrum only 2-3 moths ago.

For example we need to fix one bug (one of many) concerning working with hardware. And we clearly understand, that we need to refactor part of our system, which works with hardware. It could take a lot of time, we understand that we need to add hardware manager, change hardware interfaces and so fouth in order to unify working with hardware. And it should be done, because if we just fix bug not changing anything, then literally tomorrow we’ll have to fix similar bug, and then another one, e.t.c. How this task should be registered? It is not a user story, because product owner (or stake-holders) wouldn’t see the result, they wouldn’t be able to “touch” it, it can’t be demonstrated to them. And it is not a defect for particular user story, because it is the behaivour of legacy code, we haven’t corresponding user story. What should we do?

I see only one solution. We should wait till stakeholders give us user story concerned this functionality. For example, stakeholders want us to add support for a new type of device. Hence we can include refactoring task to a bunch of tasks under this user story.

But our system has been in development for a long time, and we added support for a lot of devices already. So it can take a lot of time till suitable user story will appear. And we should just wait and fix bugs?

And how to register bugs if we don’t have corresponding user story?

Another one situation we faced yesterday. If we have user story, which involves a lot of changes in architecture. That is user story contains a lot of task, but these task can’t be accomplished separately, and they are not user stories themselves, because they are technical tasks (refactoring and researches). It’s clear that we can’t show them to stakeholders, but we can’t accomplish user story not accomplishing these tasks. And we think, that we won’t be able to accomplish all these tasks in one sprint. And I don’t know how we can decouple 1 user story intro several user stories. What should be done?

Correct me please if I am wrong in my interpretation of user stories. I think that user story is “something” useful to stakeholder. Stakeholders can “touch” user story, they can take a look at it, they can play with new functionality and so fourth. Hence anything that can’t be demonstrated to stakeholders is not a user story, is it so? Stakeholders are not interested in tasks, they want to know only 2 things: What and When, they don’t want to know How.

And I have another one question concerning terminology. What does “epic story” mean in terms of user stories? How does it compare to user stories?

Looking forward to your reply.

Best regards,
Dmitry Lobanov

OK – so here’s my take on the questions raised:

User stories: I’ve had to deal with the question of what a user story is quite a few times over the years. There are many theoretical definitions – and I don’t care about most of them. In my opinion, the only thing that matters is this – a user-story should add business value. That raises the obvious – shouldn’t everything you do while working on a project satisfy this criteria? Yes, it should – and this is usually something that business stake-holders understand quite well.

There are several kinds of stories. The first is the obvious “feature” stories that have a GUI etc. This is the category of stories that can be “touched” and is “tangible”. Justifying this one is easy – indeed, these are the ones most commonly requested by the business.

Then there are the “technical” stories that don’t have a UI – e.g. – “store the uploaded data in a compressed format because the space used up by the system right now is costing us too much money”. Again, the value is obvious.

The next category is bugs – fixing these delivers clear value and are no trouble to manage as such. See below for more information.

One other type of story is the spike. These are easy to deal with since it is obvious what value they deliver – namely an experiment to determine if an approach might work.

The final variation is stories that deal with paying down technical debt. These are harder to justify because the business is usually not technical enough to understand these. There is no easy answer to how to sell these – but there is usually a very tangible benefit that can be attained by playing these cards. Usually this benefit is deferred – allowing the team to build new features faster, or reduce the number of bugs being discovered in a subsystem. When put in these terms the business is usually quick to understand – and then it boils down to a question of ROI. The cost of implementing these cards should be less than the savings they represent. It is important for everyone on the team to see the whole – and make these decisions together. The key is to sell the business on the value these stories delivers as opposed to the technical details. And by the way, this should be done whenever the debt starts to weigh heavier than what it should. A clean code-base is a happy code-base.

How to deal with bugs: The short answer is I usually treat bugs as stories. They don’t need to be associated with a specific user story. A bug is a bug – it doesn’t matter how it came to be – (of course, it is often related to a story – and most often the same developer ends up fixing such bugs) – and I track them in the same system used for stories. I also let the same prioritization process determine which ones get fixed and when. Further, some bugs are so tiny that they may even get fixed without there being any record of them at all. Some are so large that they might actually result in multiple stories – especially if a redesign is required. Keeping in mind that it is cheaper to fix bugs sooner than later, bugs can be managed just like any other story.

So – to recap, I don’t care for the theoretical definition of user-stories – that they should be tangible and what not. Instead, I recommend that folks do what makes sense for their situation. If I had to give only one tip around stories, it would be this – keep them small. This mnemonic might help.

Finally – about epic stories. An epic is merely a feature (or some technical aspect of the system) that is way too large to be completed as a single user-story. It is epic, because it is a large story 🙂 I always keep playable stories down to less than 2 days in length – as far as possible. Epic stories, therefore, must be managed by breaking them down into incremental chunks of functionality. This is possible about 95% of the time – sometimes however when some spike is involved or some hairy technical refactoring is needed – longer stories can be played.

I hope these thoughts answer some of the questions. I’m sure other folks have different experiences and different solutions to these issues – and that’s fine too, since agile is all about adapting.

Design for throwability

Build one to throw away, you will anyhow. — Fred Brooks

Fred Brooks said what he did many, many years ago but it is probably just as true today. How many times have you and your team gotten a few months into a project only to realize all the design mistakes you made? Ask any engineer, and they’ll tell you they would build it right the second time.

This is just reality, the nature of discovering the complexity of the domain or the technology or the usage pattern or whatever else you didn’t know about when you started.

On the other hand, there’s this [what Joel Spolsky says about rewriting software] –

It is the single worst strategic mistake that any software company can make — Joel Spolsky

So… what gives? The answer, IMHO, is basically two things –

1. Understand and internalize the idea of the strangler application

2. Architect your system in such a way to support strangling it later

In essence, this means that because it would be a bad idea to rewrite the entire system from scratch, it must be built in a way so as to enable swapping out components of it as they are rewritten (or perhaps heavily refactored).

The architecture must draw from an approach called  concurrent set-based engineering (CSBE) – and indeed, sometimes each logical component would have more than one implementation. At Runa, two components of our system actually have two implementations each. And in each case, they’re both running in production – in parallel.

The way we accomplish this is through very loose-coupling. Additionally, because we take a very release-driven approach to our software process, our architecture evolves according to our current needs… and we refactor and extend things as new requirements are prioritized. At all times, despite our super-short release-cycles, our goal is to always have a version of the system in production. Whenever our pipeline tells us that a peice of the existing design may not work in the long term, we start to work on the replacements – more than one, and in parallel.

We run them in what I’ve been calling shadow-mode. This implies that its not quite part of the official system, but is running in order to prove some design hypothesis. Once everyone involved is satisfied with the results, we pick the most suitable sub-system and decommission  the other contenders (including the old one). At Runa, we achieve much of our inter-component loose-coupling via messaging (our current choice is RabbitMQ).

To summarize – we design everything  with one over-arching goal in mind  – the thing will be thrown away someday, and be replaced with another. As I said before, this enforces a few things –

1. Loose coupling

2. Clear interfaces between components

3. Good automated system testing!

About that last point – because we have many moving parts, functional testing becomes even more important. We currently use Selenium for true functional testing (Runa is a web-based service) – and a variety of other home-grown tools for custom systems testing. Not only do automated system tests tell us that the collaborating set of components are working right, but they also allow us to change things with impunity – knowing that we’ll know if things break.

This thinking is what I’ve been jokingly calling Design For Throwability – and it’s been working rather nicely. It’s essentially a design philosophy that embraces CSBE – and is especially useful for small startups where everything is changing quickly – almost by definition.