Tag Archives: startups

Microconf Takeaways

Rob Walling and Mike Taber at the kickoff of microconf 2014

Rob Walling and Mike Taber at the kickoff of microconf 2014

Just had a great time in Vegas with some other small startup guys talking about how to create something that has real value for people — how to help folks in the world. As a side-effect, the goal is to work from home, spending lots of time with your family. It’s no get-rich-quick scheme: everybody has to find their own path. But there are a lot of common things too. Most of us use the internet, most of us either used to program or program now, most of us are part of something called the Micropreneur Academy, and most us, well, are nerds.

Here are the three things I learned (or re-learned) about myself this year:

I don’t know enough about the customer. Yes, I know the job of people I’m helping. Yes, I know the subject area I’m trying to teach. But while I have general and in-depth knowledge, that ain’t cutting it. I need to climb inside my customer’s head, spend time with them doing their work from their point of view, not mine. I keep wanting to jump ahead to the business-building part of things, instead of product-market fit. If I get the right product-market fit, the market will “pull” the rest of the business from me. People will be clamoring at the door demanding that I take their money. If I don’t? Then I’m building something and trying to beat people over the head with it. Don’t do that, Daniel. It hurts.

Hey, I actually know this stuff. Since I’m trying to help people create, maintain, and optimize their to-do lists (backlogs), it would help if I knew what I was talking about. The more I interacted with fellow startup guys, the more I realized that I actually could help these folks too. I’m actually on to something very useful across a broad market. In fact, because book 3 is going to be on backlogs and startups, I can start “eating my own dogfood” and use the things I know in the work I’m doing. It sounds like I am an idiot for not knowing/doing this already, I know. But a lot of times there’s really obvious stuff right in front of you that you miss because you’re in the weeds. Jesse Mecham gave a great talk yesterday about this. He was running a profitable startup for years and still afraid to quit his day job because of his desire for security. It took going to a minister for somebody to convince him he had the answer all along.

Teach more to make more friends. This is one of those things that I understand intellectually, but I don’t think I really get it. Plus, as somebody who took years to learn a few things, I’m seeing these guys become experts in stuff that took a month or two, and then overgeneralizing what they know and saying things that aren’t necessarily true. This makes it tougher on the next guy who comes along who tries to take the reader to the next level. But I understand that taking somebody on a journey of learning with you is good for both of you. I need to keep banging this against my head until it sinks in.

My three action items:

Start talking to people on the phone. Once they sign up for the email course, ask them if they have a few minutes to chat. Get to know why people are interested in learning more about helping Agile teams. There’s no agenda: I’m not trying to sell or push products. Simply trying to gain as much loosely-formatted and unstructured data as possible that I can then go back and find themes and put some structure around.

Use my backlog principles to organize my own startup work. Hey, if the goal here is to complete a series of books that wraps up value creation from customer development to 20,000-person enterprises, time to put the stuff in book 3 to the test personally, instead of just reading about it and watching it. The startup part is probably part of the series I’m weakest on, so nothing like the present to fix that. Not only does this make sense, it’s only an hour or two of work, maybe every month or two. No biggie. (Which is one of the beauties of getting this out to folks, it should take a tough thing and make it much easier)

Revamp my email strategy. Right now I have an Agile Tune-Up email series that runs every week over a period of a year. The purpose is to get to know folks, start a conversation, let them know who I am and that I know some stuff that could help them. That’s about it. I really should 1) offer a free multi-part course or something else of value in return for folks joining the list, 2) re-vamp my weekly series so it’s more useful to the readers, 3) manually test out the emails that go out before I automate the process so that the formatting, message, and timing is exactly what I want, and 4) add in a bit of data around segmentation when people join the list so I can help them better. Are they coaches? Guys working at a big corporation? A startup? I need to create a trial scoring system and hook that into the people I interact with. Powerful idea from Brennan Dunn yesterday. Looking forward to implementing it.

As soon I finish creating the 17 clones I will need to do all of this.

But wait! There’s more! I have a couple of strategic bonus problems that need to be solved right away.

Videos or books? I’m halfway through Backlogs 2, and I only have an early version of the first of eight videos completed for the Backlogs 1 series. Looks like completing either of those two projects should take a solid 3 months. I can’t do both — or rather if it’s possible I don’t understand how. So what to do? Finish the video series so that folks can have the hard-nosed, detailed, deep-dive down on personal and team backlogs after they finish the first book? Or go ahead and continue the story with Smith and the plant, giving people more entertainment — perhaps even finishing the final book — then swinging back for the videos? Maybe neither? Maybe I just stop now and go start marketing the hell out of the book I’ve already completed. Beats me, and I’m the one supposed to be figuring this stuff out.

All-in-all, it was a great conference. Lots to think about, great folks, and some terrific tactical advice that I didn’t even get into here. Good stuff.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

F#, Mono, Agile, Architecture, DevOps

Several people have asked online lately, “Can you really write production code in F# and mono?”, “How are you doing architecture now that you’ve switched completely to F#”, and “Aren’t you doing some kind of weird thing now that doesn’t work with interactive websites?”

I usually don’t do coding blogs, because, frankly, after a while it all gets pretty boring. Same old bytes, just new bells and whistles on top. But my approach to architecture has changed in a major way over the last five years. Might as well document it.

Description of Problem Domain. For our sample project, let’s take Newspaper23. It’s a production system with a small number of users that’s been running for a few years and has evolved through my change in philosophy.

Newspaper 23 exists for one reason: I have a very short attention span. Websites are always trying to get me to hang around, click on related stories, sign-up for things, and so on. I find this very distracting. It’s very easy for me to spend a lot of time online that’s unproductive. So a few years ago I had an idea: since the news I consume is all from a dozen or two sites, why don’t I just harvest the titles and links from those sites and put them in a big list? Then I’m choosing what content to consume based on the site brand and the title of the article, not social cues or any other nonsense.

So I got out my credit card, went over to Amazon AWS, and fired up the site.

The Old, Old Way of doing things. The first time through, I did this in a “classic” manner. I sketched out a domain model, I elaborated a bit on a database model, I built a database model in MySQL, and I created a new C# app in Visual Studio and wrote a program to do everything that was needed — get some links, save the data about them, create a page with the links, do some “other stuff”.

The problem was, I was never really clear what the program should do. Should I collect the votes the article had from reddit? Don’t know, so I’ll throw that in there and save it. Might need it later. Should I provide the ability to comment, or vote? Don’t know. I’ll add space — after all, space is cheap — and if I need it, it’s there. Should there be some kind of authentication? Beats me. (Decided to skip that one)

Don’t get me wrong; none of this was a heavyweight or Big Design Up Front process. I’m only talking about an hour or two of doodling around with things. And the beauty of modern tools is that it really doesn’t matter whether your table has 5 fields or 10. Unless you’re writing the code to do something with the data, it’s just “out there”.

It did make the “link sucking” process a little more complicated, because with different sites I had to get different pieces of data. Fair enough.

What happened. After a couple of weeks of off-and-on coding, I got the program up and running, along with a unique system for identifying data on a web page to harvest. (It was a recursive RegEx language. Please, no “but you can’t use Regex on html!” It looked good.) The code base consisted of a data tier, some controller logic on top, and it seemed to work fine.

For a while.

But over a period of just a few days or weeks, it seemed like there were always these weird edge cases, both in the sites, and more disturbingly, in the tool version, setup, and configuration. Site X would change their format, and I’d be in the code changing the way I received links. Yes, I had hard-coded in the parameters for each site, but how difficult was it to change some hard-coded values once or twice a year? Except the more source code there was, and the more I touched the code, the more errors I got. And it seemed like for one reason or the other with this way of programming there was a boatload of code to wade through and I was always horsing around with it. [insert discussion here about TDD]

By using a MVC paradigm, I had written one piece of software that I could easily lay a bunch of different controllers down on. In fact, as we all know, I could develop a “controller library” over time that would take the data and do all sorts of wondrous and amazing things. That’s the beauty of a good model — it facilitates many different solutions.

I still think this might be the way to go, assuming 1) you use good testing practices, and 2) you’re going to constantly be under the hood in the code for a long time. But it introduced all kinds of problems related to having everything pass through one executable and code base. Did I really want to horse around with the code that grabbed links, for instance, simply because I was fixing the code that wrote the web page? Why was I putting all of my eggs in one basket? OOP is a great way of doing things, but it introduces a freaking huge amount of hidden interdependencies. Some times I wonder if 90% of the problems development teams have with programming is based on the fact that in the developer’s mind there is separation of model and controller, but that in the wiring itself, things can be all hooked together in completely insane ways, usually for what seemed like good reasons at the time. The black box of OOP has a lot of very sharp edges.

The Old Way of doing things. The first thing I did was ditch C#. It’s a great language, a better Java than Java, but it was the wrong paradigm for me. The second thing I did was start to build the app from the ground-up. Programming functionally required me to write functions that did things. This sounds blazingly obvious, but it’s actually a much different way of looking at things from creating a model and adding controllers on top. I still used the MySQL datastore — had to put stuff somewhere — but my code was a LOT smaller.

It also needed much less tweaking. Remember: this is personal programming. Instead of sitting on top of a model that could do many things and having to choose what to implement, which might cover calls all over the place, my code did a few things, and there was a clear path to the data for the things it did.

What happened. There was still that problem with everything running through one spot. If I wanted to tweak anything, anywhere, I’m opening up the entire codebase to make a change.

Interestingly, since this was revision 2, the code ran for much longer without needing tweaking. This meant that when I did get around to tweaking it, I had forgotten the build setup! So I’d have a 2-line change that would require screwing around with re-remembering the build-deploy environment. That might take several hours. Plus the sites were still hard-coded. The output was hard-coded. As much as I loved data-driven programming, why was everything so coupled?

Along this time I built HN Books, a social book site for hackers. It was all static. I found I could do a lot with static web pages and JSON files. Much more than most web programmers would believe.

Hmm. Fuctional programming. Static pages. Hmmm.

The way I do things now.

So now I have a new philosophy:

  • Third time through, I decided I write small programs. As small as I can. Instead of one big honking system, my system has four programs: GetLinks, UpdateArticleLibrary, CreateSelectedArticleList, and FormatSelectedArticleList. There’s a bonus utility, CheckXPath, which lets me check out XPath strings against websites to make sure they work (in case the site layout changes). I use as few external libraries, tools, or frameworks as possible. Over the years, I’ve found that every tool I picked up had 40 tons of features, of which I only needed 3. That meant that whenever I needed to do something simple that I had never done before, I had to wade through all sorts of forums, hearing about all sorts of arcane switches and other stuff. Screw that. I do not need to buy and operate a nuclear attack sub to go fishing from the pier. So — no Visual Studio, no MySQL, no complex dependencies at all. (Having said that, I actually dumped my custom link-sucking system and went with HtmlAgilityPack. I mean heck, once it’s installed, it’s just XPath. Time spent learning XPath is not as completely sunk as time spent learning WhizBang 7). Simplify.

  • My files read and write data on the local storage. I’m not doing transactions, therefore I don’t need a transactional datastore. It’s functional coding. Things come in, things go out. The O/S already has a wonderful tool for storing things. It’s called a file system, and unless I’m going to be moving around tens of thousands of these things, it’ll work just fine, thank you. Simplify.

  • I use the O/S to schedule when the programs run and to move things around. Instead of having one program that runs once a day, split the work up into a “pipeline” and have the O/S manage the pipeline. It’s already good at managing processes — it has all kinds of tools for it. Use them. Simplify.

  • I don’t “interact”. I process things at certain times. In the old days, I’d have an instance of my program spun up in Apache, waiting around in fastCGI for a client to come and connect. Then the program would do all sorts of things depending on which client it was, what the request was, and so on.

    After many, many years of coding like this, I had to ask myself: why? Why the hell am I doing it this way? 9 times out of ten I’m delivering the same content. 9 times out of ten the client is just reading stuff. 9 times out of 10 I’m creating database connections, cursors, and all sorts of other cruft — just to send the same stuff back down the wire as I sent 2 seconds ago. For the huge majority of the use cases I can imagine, even for interactive sites, there’s no difference at all to the user between a program that sits waiting for connections and a series of programs that updates data every few seconds. This is stupid. Don’t do this any more. Decouple. Simplify.


  • I write simple queries to monitor how things are moving through the pipeline. Quite frankly, the system is running so well I don’t need to monitor it, but if I did, I’d simply monitor how things flow through the pipeline. I could even make a nice html page with graphs. Don’t need to, but it’s an easy option. In fact, I’d argue that the only things interesting to me as a owner/maintainer would be things visible at a system level, not a programming level. Huge win here: no programming skill required to look at CLR innards, just O/S skills. Simplify.

  • Nothing exists as hard-coded data. It’s all either config files or command-line parameters. Right now as I bring up the page, I can see that Hacker News isn’t returning any data. If I wanted, I could probably figure out what the problem was and fix it (assuming it was fixable on my end) in about 10 minutes. No programming required. All I need is a shell. I AM re-coding the system, kinda. I decided that since I have 10-15 functions that are the same across each executable, it would make sense to create one Visual Studio solution and share a couple of library source files. Welcome back to the days of shared C header files! I’m also making the logging more robust. Right now I log everything. (I don’t read the logs, but they are there.) This is using up too much disc space. Every few months I have to clean it out. So a more fine-tuned logging system would be nice. Maybe. Maybe not. Simplify.

  • TDD? TDD? We don’t need no stinking TDD. With purely functional programming, there are only 3 mistakes I can make: Failure to break down transforms into understandable atomic units, failure to describe the transform correctly, and failure to validate the data. If I do all three of those correctly? There’s nothing to test. It’s like trying to test an SQL select statement. The idea doesn’t make sense. Simplify.

It’s very nice. Here’s the main function for the first program in the chain, GetLinks, that gets links from sites (duh):

Code Snippet
  1. [<EntryPoint>]
  2. let main argv =
  3.     try
  4.         let opts = parseCommandLineArgs (Array.toList argv)
  5.         if opts.verbose >= Verbosity.Normal then
  6.             printfn "Options Selected:"
  7.             printfn "%A" opts
  8.             printfn ""
  9.         let config = getConfigData opts
  10.         let outputDataHolder = {
  11.             outputSections = new System.Collections.Generic.Dictionary<string, outputSection>()}
  12.         let outputData = ripLinks opts config outputDataHolder
  13.         printfn "Processing Complete for %A" opts.siteUrl
  14.         let numberOfDataPointsMatchMessage =
  15.             if outputData.outputSections.Count>0
  16.             then
  17.                 let max = outputData.outputSections |> Seq.maxBy(fun x->x.Value.outputList.Count)
  18.                 let maxCount = max.Value.outputList.Count
  19.                 let min = outputData.outputSections |> Seq.minBy(fun x->x.Value.outputList.Count)
  20.                 let minCount = min.Value.outputList.Count
  21.                 if maxCount = minCount
  22.                 then
  23.                       maxCount.ToString() + " links with " + (outputData.outputSections.Count-1).ToString() + " pieces of additional information about each link gathered."
  24.                 else "Number of links, titles, and other Data DOES NOT MATCH.\r\n" + max.Key + "  has " + maxCount.ToString() + "entries while " + min.Key + " has " + minCount.ToString() + ".\r\nCheck your configuration file or run this program with the verbose option set /V"
  25.             else
  26.                 "\r\n\r\nTHERE WERE NO SECTIONS OUTPUT.\r\nPlease check your configuration file.\r\nTry running this program with the /V option"
  27.         System.Console.WriteLine(numberOfDataPointsMatchMessage)
  28.         0 // return an integer exit code
  29.     with
  30.         | :? UserNeedsHelp as hex ->
  31.             System.Console.WriteLine("You'd like help")
  32.             System.Console.WriteLine("Good luck with that")
  33.             System.Console.WriteLine("/V for verbose output")
  34.             System.Console.WriteLine("/S:<url> to set the target site url")
  35.             System.Console.WriteLine("/C:<filename> to set the config file used. Config file is expected to have Windows line returns \r\n")
  36.             System.Console.WriteLine("/O:<filename> to set the output file created/overwritten")
  37.             System.Console.WriteLine("/N:<integer> number of links desired")
  38.             System.Console.WriteLine("")
  39.             0


This is 50 lines of code. But it’s really only 4, lines 204-207. It gets the configs passed in. It creates a new container to hold the output data, it processes the link, and then it saves the data (which happens in the ripLink function. Should be down in this one. Ugh.) The rest of it is logging and help system stuff.

I could show you ripLinks, but it’s the same deal: 50 lines of code which are really about 10. It gets the links from the page using the “ripLinksOnAPage” function (clever naming, eh?), then it processes the links according to the config file.

Let’s look at how it breaks up.

wtf-blog-getLinks-fd

As you can see, there are really only 5 functions, ripLinks, http, loadHtml, recBuildLinksUp, writeLinksOut, and ripLinksOnAPage. The rest is either library calls or a few small helper functions. Take out the logging and some of the other broilerplate, and there’s maybe 50 lines of “real code” here.

We’ve done something simple, easily describable, and concrete. We took stuff from the file system, read a webpage, wrote stuff to the file system. Logged as we went along. That’s it. No need to solve world hunger. It has value.

This code has been running for more than a year with no modifications. I expect it to continue running forever. I’m done. Isn’t that nice?

Common objections.

It’s re-inventing the wheel. In most cases, I don’t need a wheel. I need a lug nut. Yes, I know what the wheel looks like, but the cognitive load of buying a big stack of wheels and carrying them around when I just need a couple of lug nuts? Tell you what. If I start thinking about round things to fit on cars, I’ll get a wheel. Otherwise I’m fine.

It’ll never scale. The funny part about this objection is the opposite is true: the more complex your stack, the more difficult and nuanced it is to scale. I can take this app and scale it out as far as I like. Heck, copy it to a CDN. We’re done. And for those of you thinking interactivity, think long and hard whether you need immediate feedback for the user or just something that changes every few seconds or once a minute. You could be spending a huge number of processor cycles worrying about concurrent clients when you really don’t need it.

It’s poorly-thought-out. My datastore? Line-delimited text files. Code complexity? Nothing more than a few hundred lines of code. Is there anything it can’t do? Not really. But (and this would be the objection I would have made several years ago) what if you want it to do something that required the data to change? Wouldn’t you have to re-jigger every piece of code in the pipeline?

Not really. First, because I’m using name-value pairs, I can always add data and not use it. So really, what would happen if I wanted some cool new feature would be 1) I’d change the data representation where it was created, 2) I’d add the code to store it, and 3) I’d add the code to use it. If you’ve worked in a functional environment, this is the way you make changes anyway. Nothing new here.

It’s not as cool as X. Probably not.

The deployment process is brittle. Actually, although I’m not continuously deploying what I write — there’s no need to automate it when it’s just me — I’m integrating DevOps directly into the solution. There’s no one part of this solution that’s “programming” and another part that’s “deployment”. It’s all integrated together. Instead of good coupling and cohesion at the function level, I have good coupling and cohesion at both the function and the executable level. Very cool stuff.

Continuing to add features. The very next thing I’m going to do is add/adjust the logging. Having to clean out the logs once every 3 or 4 months is a chore. Next up in my quest to eliminate distractions, I’ll probably go to the target site and rip the plain text and store it here. I’ve thought about adding voting and commenting, but it’s a personal site.

None of this will require a major change or a re-think of how the architecture works. Mostly the system just works and I don’t have to mess with it. O/S updates handle updating security and scaling problems. I worked a bit to make the solution, and now the solution works for me. And isn’t that the entire idea?

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Life, The Universe, Startups, And Everything

Recently I finally figured out what I’m doing in my startup.

Not how to succeed — growing very large is still ahead of me — but how to know what to do next. Here’s what I learned.

I have two theories to test, a value hypothesis and a growth hypothesis.

Value hypothesis: if I present this to you, in this format, you will exchange with me something that I find valuable. Perhaps money. Perhaps your time.

Growth hypothesis: if I do these things, I will be able to present my value proposition to X number of new people.

One of these is called sales, the other marketing. But do not be concerned with business-sounding words. You don’t have to start reading tons of business blogs or building imaginary worlds with spreadsheets. In fact, that can be very dangerous, as it causes you to emotionally bake-in ideas that most likely are completely fallacious. Just look at it like all you have is these two very tenuous theories.

Your job is to make very precise and defined hypotheses — if I do X, Y will happen — then run a test on them to see if they hold up. You are a scientist studying a completely unknown field of study. Come up with two hypotheses, one value, one growth, then test them. If they fail, change the hypotheses until they pass. A failure is a good thing! But it means you need to decide whether to give up or pivot. Most new people to startups build some huge product — one hypothesis — and never really test it. Good startups build dozens of testable hypotheses and test rapidly. Bad startups take forever to get to a test. Or they run out of money long before they ever get around to it.

Here’s the critical thing: The goal is the passing test, nothing else.

Value hypothesis: if I show a bunch of people a bushel of apples while they are at the flea market, 5% of people will buy one for one dollar.

Growth hypothesis: if I give you half-off an apple in return for your wearing an “I bought the best apples ever at Joe’s Booth!” badge, you will bring by two other people who will also buy apples.

By creating and continuing to define these hypotheses, you build a self-sustaining system of creating value, or a business. One way to break down your two theories into finer hypotheses is like this:

lean-canvas

But there are others. As you make your hypotheses more and more detailed, you start creating a very defined structure to the test. This structure is your business model. A business cannot succeed — or fail — without creating and testing hypotheses. If you’re not testing hypotheses, you have an expensive hobby, not a business.

Want practical value? Create a Kanban board around the hypotheses you are testing, color-code your tasks to match up to what you are testing (Trello is really nice for this). Then you’ll know that every thing you do each day is for a reason. You’ll also be able to prioritize your time and energy better.

Write these down. Put them in a public, visible place for you. Everything you do — go to seminars, learn how to sell, read a book on startups, watch a video on programming, life, the universe, and everything else for a startup — everything fits into this model.

Use it.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

The Startup Story I Want To Hear

Been listening on my iPod to Andrew Warner interview a ton of founders. Wow, I think he’s up to over 600 now? He said something the other day about having some criteria for people he spoke to: he only wanted to talk to people who had made it big, who had a powerful story to tell.

Likewise I also spent last week at #Microconf 2013 down in Vegas. What a great experience! Some folks have called it the best conference they’ve even attended. Beats me, this was my first, but I had a blast. Lots of people who had successful startups taking the time to share what they knew with the rest of us. Last year they were sitting in the audience. This year they’re making 5-digit profits or more each month.

But there’s a type of story I want to hear that I haven’t heard yet. I understand that startup success is a mix of many factors. Some factors I can control; others I cannot. Luck plays an important part in it. After listening to a zillion stories and reading books, I’ve had enough. I’m not buying into the idea that startup stories need to have a hero and be dramatic. I’m separating the “self-help” part of this genre from the nuts-and-bolts part. I’m not buying into the idea that some part of Mark Zuckerberg is “magic”. Yes, he had the execution nailed, but he was also the right guy in the right place at the right time. No business porn for me. I want struggle, not Disney.

I want to hear the opposite of the traditional startup story because I think it speaks to many more of us.

I want a story about a person that struggled for many years. That made lots of mistakes. That learned lessons the hard way. That eventually combined the right idea with the right execution in the right market to make a living. Not buy a boat you can land a helicopter on. Not conquer the world with iPads. Just make a living. The real startup story that most people live.

In the startup community, we keep emphasizing the dramatic, the kids out of college cashing in on a billion-dollar IPO. But hell, that’s not the story that any of us who are actually doing the work are actually living. We need more realistic success stories if we truly want to help each other out.

Tell me more of those stories. Please.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Introduction to the Group Grope

The military is a wonderful experience in life. Where else can you learn that a “Cluster Fuck” is a bunch of people busily working hard at nothing intelligible or productive? It’s a profane, yet colorful description of a business process many of us see every day. (Nice people use the phonetic terms. “Hey, look at that Charlie Foxtrot!”)

Yesterday when doing my startup standup startup blog entry, I used another one of those terms, not heard as much, the group grope.

Ever been to a group grope? If you’ve spent any time in the business community, I’m willing to bet you have.

A group grope is when people, who do not bear responsibility, assemble for purposes of solving a problem which none of them have the information or skills to solve.

So that last time your team got together to talk about source control, when none of you have the power to make a decision about what to do, or even have experience using various tools? You know, where you left feeling pretty good, but with the vague feeling that things were unresolved? That’s a group grope.

Group gropes are fun, yet subtly frustrating. You get to take time off from work, see your friends, talk about some issues of importance, get caught up. That’s all great. The next step, and the key indicator of a good group grope, is when each person asks the other what they know or can do about the problem without getting any positive result. “I don’t know how marketing feels about that, Bob, have you spoken to them?” “Those guys in marketing are doing a great job, and I’ve heard it could be a problem, Frank? Have you met with them lately?”

It’s like a Scooby Do episode where the mystery is never solved. It’s just a bunch of kids wandering around asking questions of each other.

It feels good, there’s a lot of fun people involved, you get to explore areas you normally don’t go into, but at the end of the day you’re left empty and unfulfilled. There’s no long-term benefit.

You can short-circuit a group grope, sometimes, by simply announcing you are in one. “Is there anybody here responsible for X? Also, guys, don’t we need some folks who know Y and guys from over in the Z department? Without them I can’t see us making much progress, can you?”

Be sure to separate a group grope from a brainstorming session. Brainstorming sessions are there to create potential ideas about a problem. The meeting ends, you have a list. You probably also have some assimilation and analysis to do to turn the list into action. Group gropes end with everybody knowing a little more about problem X, mostly trivial stuff, but nothing else of value can be gained from it.

Sometimes when you’re in a group grope you can stop it. Many times you cannot. Many times it’s just best to lie back and think of England. But if you’re the one responsible for setting a meeting up, and somebody calls “group grope” on you, it’s a good time to either kill the meeting and let folks return to work — or figure out what the hell you’re all supposed to be doing that’s going to be useful to the company. Don’t confuse social fun and a sense of learning with accomplishing something valuable.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Startup Standup Startup

standup-iconsI’ve been coworking at a nearby town and a couple of us decided to try to help encourage each of us in our startups.

Being a startup junkie and an Agile Coach, I thought, “Why not a startup standup?” Each week we meet in person. There, each of us announces what they accomplished in the last week, what they’re planning in the next week, and what they’re number one problem is. No classes, no group-gropes, no fluff. Immediately after the ten-minute standup we can each help each other if one of us has an obstacle that we know about. Plus we can help each other position our work mentally in order to focus more on the right stuff and less on the wrong stuff.

So how to describe what we should be talking about?

I pulled down a couple PG essays, a blog on the Lean Startup concept, and some notes Derek Sivers made while reading the Lean Startup book. But heck, it was still too much verbiage. Put together, it was WAY too much to expect noobs without context to plough through. I decided to cut a bit. So here’s an effort to make a crash course in what you should know and talk about during a weekly report of your activities in a startup. I liberally edited for clarity and brevity.

1. What is a startup? (From PG’s 2012 essay)

Not every company is a startup. Millions of companies are started every year in the United States. Only a tiny fraction are startups. Startups are companies that make something people want that have the ability to scale rapidly. They may or may not involve technology.

For a company to grow really big, it must (a) make something lots of people want, and (b) reach and serve all those people. Barbershops are doing fine in the (a) department. Almost everyone needs their hair cut. The problem for a barbershop, as for any retail establishment, is (b). A barbershop serves customers in person, and few will travel far for a haircut. And even if they did the barbershop couldn’t accommodate them.

Writing software is a great way to solve (b), but you can still end up constrained in (a). If you write software to teach Tibetan to Hungarian speakers, you’ll be able to reach most of the people who want it, but there won’t be many of them. If you make software to teach English to Chinese speakers, however, you’re in startup territory.

Most businesses are tightly constrained in (a) or (b). The distinctive feature of successful startups is that they’re not.

 

2. Do you need a cool idea?

No, you do not.

3. What are you concentrating on and talking about while you are developing your startup? You are creating and testing value and growth hypothesis. A value hypothesis is a concrete way to determine what you are doing has value to your customer. A growth hypothesis is a concrete way to determine how you gain new customers. These are both measurable, and you have to have real results that indicate success or failure for your hypothesis. That means heavy, direct interaction with the people you are supposed to be making things that they want. More Lean Startup goodness from Sivers’ notes:

Startups are human institution designed to create new products and services under conditions of extreme uncertainty.

The stories in the magazines are lies: hard work and perseverance don’t lead to success. It’s the boring stuff that matters the most.

Startups exist to learn how to build a sustainable business. This learning can be validated scientifically by running frequent experiments.

The goal of a startup is to figure out the right thing to build – the thing customers want and will pay for – as quickly as possible.

Too many startup business plans look more like they are planning to launch a rocket ship than drive a car. They prescribe the steps to take and the results to expect in excruciating detail, and as in planning to launch a rocket, they are set up in such a way that even tiny errors in assumptions can lead to catastrophic outcomes.

The customers failed to materialize, the company had committed itself so completely that they could not adapt in time. They had “achieved failure” – successfully, faithfully, and rigorously executing a plan that turned out to have been utterly flawed.

Instead of making complex plans that are based on a lot of assumptions, you can make constant adjustments with a steering wheel called the Build-Measure-Learn feedback loop. Through this process of steering, we can learn when and if it’s time to make a sharp turn called a pivot or whether we should persevere along our current path.

Validated learning is the process of demonstrating empirically that a team has discovered valuable truths about a startup’s present and future business prospects. It is more concrete, more accurate, and faster than market forecasting or classical business planning.

Learning is the essential unit of progress for startups. The effort that is not absolutely necessary for learning what customers want can be eliminated. I call this validated learning because it is always demonstrated by positive improvements in the startup’s core metrics. As we’ve seen, it’s easy to kid yourself about what you think customers want. It’s also easy to learn things that are completely irrelevant. Thus, validated learning is backed up by empirical data collected from real customers.

Learn to see every startup in any industry as a grand experiment. The question is not “Can this product be built?” In the modern economy, almost any product that can be imagined can be built. The more pertinent questions are “Should this product be built?” and “Can we build a sustainable business around this set of products and services?” To answer those questions, we need a method for systematically breaking down a business plan into its component parts and testing each part empirically.

One of the most important lessons of the scientific method: if you cannot fail, you cannot learn.

A true experiment follows the scientific method. It begins with a clear hypothesis that makes predictions about what is supposed to happen. It then tests those predictions empirically. Just as scientific experimentation is informed by theory, startup experimentation is guided by the startup’s vision. The goal of every startup experiment is to discover how to build a sustainable business around that vision.

A minimum viable product (MVP) is simply the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort. The goal of the MVP is to begin the process of learning. Its goal is to test fundamental business hypotheses.

Most entrepreneurs approach a question like this by building the product and then checking to see how customers react to it. I consider this to be exactly backward because it can lead to a lot of waste. First, if it turns out that we’re building something nobody wants, the whole exercise will be an avoidable expense of time and money. If customers won’t sign up for the free trial, they’ll never get to experience the amazing features that await them. Even if they do sign up, there are many other opportunities for waste. For example, how many features do we really need to include to appeal to early adopters? Every extra feature is a form of waste, and if we delay the test for these extra features, it comes with a tremendous potential cost in terms of learning and cycle time. The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time. [Which may include actually building anything at all]

(Dropbox:) To avoid the risk of waking up after years of development with a product nobody wanted, Drew did something unexpectedly easy: he made a video. The video is banal, a simple three-minute demonstration of the technology as it is meant to work. It was all he needed at first to test a value hypothesis. Many entrepreneurs refuse to spend any time in development at all until some initial value and growth hypotheses have been tested in the real world and they have real metrics from the tests. (Anecdotes, like “I showed it to twenty people and they liked it” are not real metrics)

MVP can seem like a dangerous branding risk. Easy solution: launch the MVP under a different brand name. Experiment under the radar and then do a public marketing launch once the product has proved itself with real customers.

Prepare for the fact that MVPs often result in bad news.

The solution to this dilemma is a commitment to iteration. You have to commit to a locked-in agreement – ahead of time – that no matter what comes of testing the MVP, you will not give up hope.

A startup’s job is to
(1) rigorously measure where it is right now, confronting the hard truths that assessment reveals, and then
(2) devise experiments to learn how to move the real numbers closer to the ideal reflected in the business plan.

The failure of the “launch it and see what happens” approach should now be evident: you will always succeed – in seeing what happens. Except in rare cases, the early results will be ambiguous, and you won’t know whether to pivot or persevere, whether to change direction or stay the course.

Entrepreneurs need to face their fears and be willing to fail, often in a public way. In fact, entrepreneurs who have a high profile, either because of personal fame or because they are operating as part of a famous brand, face an extreme version of this problem.

I recommend that every startup have a regular “pivot or persevere” meeting.

Remember that the rationale for building low-quality MVPs is that developing any features beyond what early adopters require is a form of waste. However, the logic of this takes you only so far. Once you have found success with early adopters, you want to sell to mainstream customers. Mainstream customers have different requirements and are much more demanding. A pivot is required.

Startups don’t starve; they drown.

Startups have to focus on the big experiments that lead to validated learning. The engines of growth framework helps them stay focused on the metrics that matter.

Companies using the sticky engine of growth track their attrition rate or churn rate very carefully. The churn rate is defined as the fraction of customers in any period who fail to remain engaged with the company’s product. The rules that govern the sticky engine of growth are pretty simple: if the rate of new customer acquisition exceeds the churn rate, the product will grow. The speed of growth is determined by what I call the rate of compounding, which is simply the natural growth rate minus the churn rate.

Focus needs to be on improving customer retention. This goes against the standard intuition in that if a company lacks growth, it should invest more in sales and marketing. This counterintuitive result is hard to infer from standard vanity metrics.

4. So formulating and reporting on hard metrics resulting from direct user contact that prove or disprove our value and growth hypotheses is what we should focus on. Once we do that, what are some common mistakes? (From PG’s 2005 essay)

  • Release Early. get a version 1 out fast, then improve it based on users’ reactions. By “release early” I don’t mean you should release something full of bugs, but that you should release something minimal.
  • Keep Pumping Out Features. I don’t mean, of course, that you should make your application ever more complex. By “feature” I mean one unit of hacking– one quantum of making users’ lives better. [Which should directly come from your hypotheses testing results]
  • Make Users Happy. There are two things you have to do to make people pause. The most important is to explain, as concisely as possible, what the hell your site is about. How often have you visited a site that seemed to assume you already knew what they did? The other thing I repeat is to give people everything you’ve got, right away. If you have something impressive, try to put it on the front page, because that’s the only one most visitors will see. Though indeed there’s a paradox here: the more you push the good stuff toward the front, the more likely visitors are to explore further.
  • Fear the Right Things. Most visible disasters are not so alarming as they seem. Disasters are normal in a startup: a founder quits, you discover a patent that covers what you’re doing, your servers keep crashing, you run into an insoluble technical problem, you have to change your name, a deal falls through– these are all par for the course. They won’t kill you unless you let them.And in any case, competitors are not the biggest threat. Way more startups hose themselves than get crushed by competitors. There are a lot of ways to do it, but the three main ones are internal disputes, inertia, and ignoring users. Each is, by itself, enough to kill you. But if I had to pick the worst, it would be ignoring users. If you want a recipe for a startup that’s going to die, here it is: a couple of founders who have some great idea they know everyone is going to love, and that’s what they’re going to build, no matter what.
  • Commitment Is a Self-Fulfilling Prophecy. I now have enough experience with startups to be able to say what the most important quality is in a startup founder, and it’s not what you might think. The most important quality in a startup founder is determination. Not intelligence– determination. [In fact, intelligence, like funding, can be counter-indicative of success.]Time after time VCs invest in startups founded by eminent professors. This may work in biotech, where a lot of startups simply commercialize existing research, but in software you want to invest in students, not professors. Microsoft, Yahoo, and Google were all founded by people who dropped out of school to do it. What students lack in experience they more than make up in dedication. You can lose quite a lot in the brains department and it won’t kill you. But lose even a little bit in the commitment department, and that will kill you very rapidly.
  • There Is Always Room. So for all practical purposes, there is no limit to the number of startups. Startups make wealth, which means they make things people want, and if there’s a limit on the number of things people want, we are nowhere near it. I still don’t even have a flying car.
  • Don’t Get Your Hopes Up. This is another one I’ve been repeating since long before Y Combinator. It was practically the corporate motto at Viaweb.Startup founders are naturally optimistic. They wouldn’t do it otherwise. But you should treat your optimism the way you’d treat the core of a nuclear reactor: as a source of power that’s also very dangerous. You have to build a shield around it, or it will fry you.The shielding of a reactor is not uniform; the reactor would be useless if it were. It’s pierced in a few places to let pipes in. An optimism shield has to be pierced too. I think the place to draw the line is between what you expect of yourself, and what you expect of other people. It’s ok to be optimistic about what you can do, but assume the worst about machines and other people.This is particularly necessary in a startup, because you tend to be pushing the limits of whatever you’re doing. So things don’t happen in the smooth, predictable way they do in the rest of the world. Things change suddenly, and usually for the worse.

    Shielding your optimism is nowhere more important than with deals. If your startup is doing a deal, just assume it’s not going to happen. The VCs who say they’re going to invest in you aren’t. The company that says they’re going to buy you isn’t. The big customer who wants to use your system in their whole company won’t. Then if things work out you can be pleasantly surprised.

    The reason I warn startups not to get their hopes up is not to save them from being disappointed when things fall through. It’s for a more practical reason: to prevent them from leaning their company against something that’s going to fall over, taking them with it.

  • Speed, not Money. The way I’ve described it, starting a startup sounds pretty stressful. It is. When I talk to the founders of the companies we’ve funded, they all say the same thing: I knew it would be hard, but I didn’t realize it would be this hard.So why do it? It would be worth enduring a lot of pain and stress to do something grand or heroic, but just to make money? Is making money really that important?No, not really. It seems ridiculous to me when people take business too seriously. I regard making money as a boring errand to be got out of the way as soon as possible. There is nothing grand or heroic about starting a startup per se.So no, there’s nothing particularly grand about making money. That’s not what makes startups worth the trouble. What’s important about startups is the speed. By compressing the dull but necessary task of making a living into the smallest possible time, you show respect for life, and there is something grand about that.

I could probably tighten this up a lot further given some more time, but it’s definitely decreased in size from the 50 pages it started out as!

Links/Sources:

So 1st, definition of a startup: http://www.paulgraham.com/growth.html

Here are some notes from the book Lean Startup. Good stuff in here. http://sivers.org/book/LeanStartup

Value Hypotheses. http://thesquigglyline.com/2012/03/05/creating-and-testing-a-leanstartup-value-hypothesis-creating-and-testing-a-leanstartup-value-hypothesis/

Finally, some common mistakes. http://www.paulgraham.com/startuplessons.html

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

How Can I Help?

I’ve decided the most important conversational phrase in the English language is “How can I help?”

I don’t come to this decision lightly. There were several others that almost made it.

“I love you” was a top contender, but it says more about my own personal feelings than my relationship to the world.

“Let me help” also didn’t make it. It focuses more on my taking control of things.

“Try this” was big, but it was more of a plea for validation than anything else. I know more than you. Listen to me and you’ll do better. Nope, at times this might be true, but it’s backwards. My relationship to knowledge is nowhere near as important as my relationship to the person I’m talking to.

“We can do better” was also easily in the top ten. I think I’ll put that at #2. It reminds me that we are all in this together, and that there is always room for growth.

Nope. “How can I help” says it just the right way. If you will tell me how you think I can help, I’m willing to give it a shot. I subvert my own interests to yours. Tell me what you’d like. How can I help?

I do a lot of things — write, speak, train, consult, coach, manage, and so forth. I find most all of them are some version of “How can I help?” I also find that when I start drifting to any of the other phrases, such as “Let me help”, or “We can do better”, I always start drifting away from the true core of what I’m doing. I become a lesser person.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Life Fills Up

Every so often, the discussion in the startup community turns to ageism. Why is it that the startup community seems to be so in love with younger people and so critical of older people as startup founders?

My standard reply is that it’s all risk: if you’re 20-ish, you can take on a lot more risk than if you are 40. Venture Capitalists can hire on a hundred startup founders for pennies, they work like dogs, and at the end of the day you get a few winners which makes the numbers work. The 20-somethings get great experience in startups and you get a few winners. As they say in the movies, it’s a win-win.

There’s also the standard answer that people have more commitments as they get older. A spouse, a mortgage, children, student loans — life quickly throws you all kinds of things that you don’t have the option of escaping. When you’re 22 you might live on 500 bucks a month. When you’re 32 your bare minimum salary could easily be five times that.

I’m in my 40s and I’ve spent quite a bit of time on startups, and I’ve found another big obstacle that rarely gets mentioned: life fills up.

After many startup attempts over several years, I’m overweight, out-of-shape and have very little social life. Why? Because I refused to fill my life up with other stuff. Everybody else I know is not like this: they all have civic groups, games, clubs, or other things they spend their time in. I, on the other hand, have always been very miserly with how I used to spend my time. I spend a lot of time reading books, for instance. Makes for a great consulting career. Gives you a shot at forming a startup. Not so good for a lot of other things.

So aside from the usual answer of risk and commitments, there’s another important consideration. Normal people fill their lives up with normal stuff. Softball games, kids’ recitals, technology groups, family events — after a while you find you have no time for anything else. I used to wonder how somebody could work at the factory for ten years, get laid off, and then not have any other skills. How could this happen? To me this was all about not having enough drive. Now I know one of the other answers: people fill their life up with all sorts of things. It’s a real-world example of Parkinson’s Law, which states that work expands to fill up the available time. Life also expands to fill up the available time.

Of course, you can always continue to argue that this is not an optimum situation. Is a life full of watching sports events and chit-chatting in you social club something you want? Or do you want more than that? Whatever your personal answer, it’s obvious to me that people who can commit huge chunks of their lives on one single-minded endeavor are very weird and strange compared to the rest of humanity. They are perhaps not as weird compared to other people in their 20s, the time of life most of use allocate for developing our skills for our careers, but the definitely stand out in the 30 and 40-something crowd.

I used to think the inability to focus narrow-mindedly on one thing just was a matter of self-discipline, no matter what your age. Now I’m thinking not so much. At some point in your life, for normal people, life just fills up.




If you’ve read this far, you should follow me on Twitter!

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Don’t Know Much

I’m having lunch with my oldest son today. He turned 25 this year! It was a big birthday for him, and a big moment for me too.

Looking over the last 25 years, I can’t help but try to figure out what’s changed. Am I the same guy I was at 21? Of course not.

A lot has changed. I think one of the most interesting changes has been in the last five years. I’ve decided I don’t know very much.

Up until then, I studied a lot, learned as much as I could about something, then dove in and took charge. In the last year or two, however, as my startups start taking off and I finish up my agile/kanban book, looking back over all of it, I realize how little I actually know.

Please don’t think I have a lack of self-confidence: I’m still the arrogant asshole I always was. But now I don’t automatically assume that the world is the way I suppose it to be. Looking at dozens of teams get more productive — and some fail — has made me rethink what it means to construct success.

In the western world, many of us are model-builders. Give us the specs, the shape of the system in question, and we will build a mental model that emulates it. Then we work the model to see what happens. If that works, we move to the real world.

As an example, if you were coding a large client-server system in the 2000s, the first thing you should do is talk about your domain model — which concepts are important enough to be in the system and which aren’t. Based on that discussion, identifying concepts and their relationships, you could continue down the path of development.

Or take playing a video game. As we play, we construct a mental model of how things work. Pull that lever there and the door opens. Do these three things in order and you can do the forth, and so on. As our mental model gets more detailed, we are able to play the game better. Life, it seems, is just a series of models that we learn to some degree of fidelity and then master.

All of this is true, but as I continue writing my book and looking back on teams I have led or coached, it occurs to me that successful teams were always rebuilding models, not elaborating even more on pre-existing ones.

If you ever worked in a successful startup, you’ve seen project managers do what comes natural to them: take what works best from each project and combine it into a master “cheat sheet” of how good projects should operate. I have seen this several times. These are all well-meaning efforts, but in the end they all fail. They hurt more than they help.

Why?

I think it’s because the human mind naturally models way far beyond anything that might be actually true. We can see a butterfly in a meadow in the morning and have a 3-page poem dedicated to it by lunch. Or — a much likelier scenario — we can observe 3 or 4 projects that do well, identify commonalities, then extrapolate that to the universe of projects.

But it’s not just technology teams, that’s the kicker. We all do this, and we do it in every part of our life, whether we realize it or not. It was learning about startups that taught this to me. You’ll have an idea, try to sit around and decide if it’s a “good” idea, then, based on that judgment, elaborate on it some more. Maybe you write some code. Maybe, if you’re new to this, you write a lot of code. Perfect code. Use a bunch of TDD and have a rock-solid architecture and implementation. Make sure you’re able to scale. Pick the best problem to solve. Use a data-driven implementation. Pick the right corporate structure. Hire a lawyer.

How can I say this nicely? There are a thousand things you can do in a startup that don’t amount to jack shit. There are very few things that are important. All of them directly relate to getting customers.

You see, it’s easier for us — it’s more natural for us — to construct these models and flesh them out, turn them into reality — than it is to actually see the real world. The real world wants an iPod app that farts when you push a button. You and I may want a super-colossal app that ends world hunger, but nobody else will buy or use what we make, so in the end it doesn’t matter. But — and here’s the crazy part — instead of adjusting our work habits to try to continually find out what the world wants, instead we create more and more complex models or what we think they should want. We love models a hell of a lot more than we love feedback.

That’s why I think being stupid and humble is probably the best attitude for having a startup. I don’t know what people want, I actively resist learning, and the best I can do is struggle with that truth.

The same probably goes for the rest of life as well, although most of us (including me) are uncomfortable looking at it like that.

I don’t know much.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

It’s All Content

I reached a conclusion several months ago that I’ve been a bit timid to explore, but this morning seems as good as any.

Basically, the internet has made everything into a commodity.

Hackers love this argument when it’s used for something that’s not dear to their hearts, like the future of record companies. Why should record labels charge so much, they ask. It’s just all bits floating around on the net, and bits got to be free.

Some hackers will take this to the logical next step, and demand that most programs should be free as well. How can you in good conscience charge for something that, while it might have a high prototyping cost, has no production cost at all? It’s all just bits. Bits got to be free.

But very few of them actually reach the logical conclusion: everything is just bits. Diagnosis for a medical condition? Just a bunch of bits representing an expert system with your personal data applied. Legal assistance? Same thing. Directions to assemble a nuclear reactor? Just bits. And bits got to be free.

Here’s an exercise for you: pick something, anything (as long as it’s some sort of service or intangible product). I can show you how it all boils down to a bunch of bits. Yes, initial costs might be quite high, but follow-on costs will drop quickly to zero.

With 3-D/Christmas Tree machines beginning to take off, this is going to spread to tangible products as well. I can easily foresee a future in which most all physical goods are just so many bits, all out there on the web wanting to be free. A song is the same as a legal document is the same as a car. They’re all bits.

As a startup junkie, this has profound implications. It means that no matter what the complexity of the code you are generating, it’s all either completely worthless when your’e done or trending towards zero at a high speed. Last year’s complicated tax preparation system that cost 80 bucks is this year’s free web app.

Well then, what actually has value? Easy one: audience participation. When you create something that has high audience participation, the involvement of the audience is the thing of value, not the complexity or value of the solution the code provides. This is why sites which emphasize the audience creating and amusing each other, say Facebook or Twitter, have so much more long-term value than sites that solve a simple problem and then disappear from the user’s mind.

In fact, let’s just be blatant about it: it’s the engagement, stupid. Everything else is content. The goal: create content that leads to engagement.

This sounds so simple as to be trite. Many of you are saying, “Sure! But if I knew how to engage users, I would already be done with my startup!”

So let me explain a bit more.

The programming you do for your startup is just a form of content, and like any other form of content, it’s value will trend towards zero over time. The minute you finish the code is when it has the most value. From there on out it’s decreasing. Of course, the idea is that your userbase increases, thereby making your startup soar. But it’s the user involvement, creating and consuming content, not the solution, that provide the value.

The best kind of content is the content — the type that has the maximum engagement potential — is content that users create for themselves. Ideally, your program will do something that will facilitate the users creating their own content which will also trend towards zero. But it will be their content, not yours, so it’s value starts much higher and there is a bigger chance of them sharing their content with others, thereby giving you the network effect which means you’ll grow like wildfire.

This might sound impossible to do unless you are making a social app, but actually it’s quite easy, at least in theory. Making a financial app? Allow your users to create an analysis of where they want to be in 3 years — then let them send themselves reminders about it each month. When your users are creating their own content, it has much more initial value. In fact, once you understand this, you can recognize that any kind of service is just an assisted form of letting users create their own content.

You should look at the programming part of your startup as just being a form of content creation, just like a marketing brochure or a sales email. This means that programming, at least in the startup sense, is very much an art, not an engineering science. It’s should be easy for you to do, and the focus should be on visual expressiveness and the emotional impact on the user — nothing else. If your startup has any chance of success, it should sell the user on the idea of their creating their own content for reuse using your app.

There was a famous scene in the movie “The Social Network” where college kids were rating pictures of other kids with an up-down vote. To the kids, what they were doing was simply something they were naturally bred to do: rank potential mates. Pretty brainless, but lots of fun. But to the guy writing the app, what the kids were doing were creating a personalized ranking system of attractiveness, a system that they wanted to share with others. From the kids’ standpoint, the content was in the pictures, but in fact the content was in their ranking. They were so enamored with the content they were consuming, they had no thought of the content they were creating. It’s a beautiful thing.

In the academic world, we look at the subjective value of the solution. In the consulting world, we look at the relationship to the client. In the manufacturing world, we look at how the features address market segmentation.

In the startup world, we look at none of that. Or rather, we look at all of that, but the only reason that it is important is in how we use it to create new content that people want to create, share, and consume. I think many of us pull down these old paradigms from places we were before and try to make them work in startups, and it’s not the same thing at all.

It’s all content.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.