from powerpoint to webapp

via Hackernews

 

In my consulting career, I've been fortunate to see similar problems multiple times -- hopefully, I'll learn from each one and not make the same mistakes the next time I encounter that particular situation. One situation in particular involves a conversation with an entrepreneur, and it goes something like this :

Entrepreneur: I have an idea for a web app that will revolutionize the [blank] industry, and make us bajillions!

me: That's great! I can tell you are passionate and excited, and that's critical to your success. But do you have enough cash to pay for this coffee?

Entrepreneur: Yes, we have some funding to get started. And I have a business plan explaining our strategy, and I have a powerpoint deck of what the product does.

Me: That's even better! I'll have another espresso then.

Entrepreneur: We'd like you to get us started on our website development. Here's our feature set for beta release. How long is this going to take? How many people, and what other stuff do we need?

Me: Ummm....and that's where the conversation gets difficult. Because the business plan doesn't go into great detail about the product (it shouldn't), and the powerpoint slides have a bunch of boxes and arrows but don't show what the screens look like or what actions the user takes, we can assume the founding team hasn't thought much about how people actually use their product.

So at this point in the conversation, I face an uphill climb. I have to explain to (and convince) my client that they have a lot of hard work figuring out how their users are going to use this tool to accomplish their tasks, what those steps are, and what they look like. I have to tell them I don't know how long this is going to take, and I doubt anyone else knows either.

Most of these conversations end with me suggesting some homework for the founders. It's kind of a toolkit of useful things that you probably need, but it's definitely not everything you need. But it's a start.

• read "Getting Real", the 37signals book. PDF, online, or print version, I don't care. Read it, and know it. When in doubt, consult this book. When not in doubt, consult this book and make sure you are still on the path. I hate to use the word 'bible', but it's the closest thing we have. It lays out the process of building a web product, from concept to delivery and beyond. If you're under 25, I guess you can real Paul Graham too.
• setup a server on slicehost for development (for rails, anyway). Easy, cheap, and upgradeable.
• likewise, set up a subversion repository to hold your source code on svnrepository.com. You could host your own, but I like the peace of mind I get knowing my source is backed up and secure. As a bonus, you get a Trac instance for bug tracking, and it includes a wiki and other tools to make developing your web app easier.
• hire a designer, probably a freelance one, to draw some wireframes for you. Give them lots of your time, because that's how you're going to figure out what exactly your app does. This is probably the most important person on your team right now, and you should be focused on this. Ideally you can find a good reference through your network, but if not post a well-crafted ad on craigslist and look at their portfolios.
• At the same time, you probably want a developer to start working on your site. Maybe the developer came first, and she's found someone designer-y to work with -- even better. Just get some stuff down on paper so you can discuss it, scrutinize it, see what works and what doesn't. If your designer is good, and you've spent enough time with them describing what you want, they should have something workable.
• Start building your product. Get your developer, or outsourcer, or nephew or whatever to hack some code.
• Your developers are probably following some sort of Agile process like Scrum. You should be seeing new features and changes on a daily or weekly basis. This is important, so you can play with your app as it is being born and give some feedback, change it, and make it better. If you're waiting weeks or months before peeking, you're doing it wrong. Good chefs taste as they cook.
• Once you have something you like, and works, and does what it's supposed to, consider doing a limited release. Announce to your friends and families, have them play with it, ask for their feedback. If you can't get your loved ones to pay attention to something you've been slaving over, well, that's not a good sign.
• While you're at it, put some site monitoring on it like site24*7.com -- so you'll know if you get swamped with too much traffic from Digg or Slashdot or nytimes.com, should they write about your site.
• Go slow. look how your userbase is growing, if it is at all. Get some more users -- email more friends, or blog about it, or buy a few Google ads. Setup Google Analytics to track visitors to your site, and learn what is working and what isn't. Measure, always measure.
• Get more feedback. Listen to your users. Make them happy. As your userbase starts to grow, spend some time thinking about how you can handle the extra load.

... and that's about it. You've just built and launched an app. Hopefully, you have some users and they like it,maybe even willing to pay for it. Maybe it sucks, and is a stupid idea. But more likely, it works, has some flaws, and could use some work. So work on it. Improve. Iterate.

Of course, what is considered 'best practices' today may not be the preferred methods of tomorrow. So I read a lot to stay on top of where the industry is going. A have a million feeds in my Google Reader account, but only a handful I consider invaluable -- including TechCrunch, Found+Read, Read/Write Web, and Signal vs. Noise.