trendpreneur

I’m no secret admirer of O’Reilly’s fantastic technical books, so when I saw there was a new iPhone app book coming out, I got pretty excited. I’ve been meaning to dive into iPhone app development for a while now, and the advent of the magical piece of magic iPad has certainly made me more keen to do so.

Enter ‘iPhone App Development: The Missing Manual‘. (Book website)

This book by Craig Hockenberry does a really decent job of conveying the experience of being an iPhone app developer, not just the technical documentation. It contains details on Japanese tax treaties, beta testing and bug-hunting, MVC and paper prototyping. It’s more like a course on the lifecycle of an app than a detailed lesson in programming for the iPhone, something that the other iPhone books I’ve read have handled in a fairly clunky manner.

Any criticisms I have for the book’s content are not really the fault of the author, but more the ’standard’ way of teaching iPhone programming, and the constraints within which a tutor must work. Number one, I am fed up of flashlights. Seriously. I’m also pretty bored with the whole “Create an app without any code!” approach.

It seems every single newbie tutorial out there tries to schizophrenically assume you have little to no programming experience, and would rather build something with as little of that nasty code as possible, while also jumping in with details on the square brackets and types and inheritance from the get go. I don’t know. There must be a better way.

Craig’s book actually handled this better than most, and I found myself bookmarking nuggets of wisdom early on, which is useful. Let’s just say, however, I’m not following it through from start to finish. Rather, I’m using it side-by-side with the iPhone Developer’s Cookbook, which is a real joy in the ‘I just want to build cool shit’ department.

If you’re the sort of person who likes following a single tutorial through without branching off on tangents though, I think you’d be more than pleased with the Missing Manual. You’ll definitely deep-dive into some nifty Objective-C syntax and Cocoa Touch specifics, tools and tricks that are used by actual developers (no, really, I googled some of them!). You’ll learn a lot about designing, testing and releasing your app along the way, too, which is great.

I’d love to see this book done as a class, actually, it definitely reads to me that way and I think it could be nicely broken into work segments. I aim to finish it and see how long the whole thing takes, for sure. I’m learning a lot, and not just about flashlights — I just can’t help it if I get distracted every once in a while and make a twitter app or tip calculator to pass the time…

Definitely worth a buy if you’re starting out with iPhone app development and ideally have some OO experience, just don’t expect it to be your only go-to book.

Really interesting debate/blogpost over at TechMeetup as a result of yesterday’s Engage Invest Exploit in Edinburgh. The main points I’m reading is that Edinburgh/Scotland needs more early stage risk money, more mentors/advisors, and a more flexible ecosystem (people willing to join startups, support networks that enable this). And yet someone has to gain; the investors, professional risk-takers, can’t see a return in 3-5 years investing £1m in 20 startups, so they won’t. Guys, Y Combinator took a long punt on funding hackers with ramen money, and it’s paying off.

Also in today’s reading, two lovely nuggets of wisdom from comments on a Fred Wilson piece on the ‘hopes and dreams’ phase (a phase that Scottish businesses either get stuck in, or never experience):

The temptation to quit will be greatest just before you are about to succeed.

If you find yourself driving off a cliff, stop driving.

Contradictory, and yet not; there’s a difference between thinking you’re driving off a cliff, and actually doing so.

I recently idly tweeted an idea which flitted through my head while considering the pros and cons of “E-School”, the Founder Institute. People asked for more, so here it is!

To build a business you need to build a product. While technical types often find the process of knocking up a quick demo webapp a walk in the park, one way a non-technical person can quickly gain feedback and respect is to build a prototype themselves.

If you have an idea for a web application – whether it’s a shopping site with a twist, an iPhone app that shows you nearby tweets, a game to teach children about finances, or a global treasure hunt – chances are you can build an early version to get the idea across quite quickly, even without much of a background in computer science.

Today’s tools are accessible and almost universal, but they can be really daunting if you don’t know where to begin. The value of creating your first prototype yourself in terms of feedback, understanding the problems you’ll have, and even the exercise of trimming down the feature set and figuring out the MVP (minimum viable product) is far, far greater than the time saved outsourcing it to the Philippines.

But where are the tools to teach you how?

There’s stuff to turn hackers into entrepreneurs, but connecting entrepreneurs with the tools hackers have at their fingertips seems much less common.

Here are some of the ideas I have around creating a resource (offline workshops? week-long intensive? online course? incubator? unconference? wiki? website/blog? book?) to help people without a technical background build a prototype of their idea quickly, and get feedback on it.

Methods

• How to design, structure and plan a web application (see below for how to build)
• Rapid prototyping, iteration, and agile development (i.e. build it quickly, get feedback, change it)
• Minimum viable product and how to figure out what should be in your prototype
• Ways to test out your application; how to find initial users and get feedback (Real stories)
• Feedback channels for prototyping before you’ve written a line of code
• How to pull off an awesome investor demo (Interviews)

Technology and Tools

• Product and feature design techniques
• How to make the most of paper prototypes
• What’s wireframing and why should I bother? Won’t the designer do that?
• Designing an awesome user experience
• Visual design basics (Analysing/Breakdown of beautifully designed prototypes)
• How to make things look good and feel polished without a degree in graphics
• Readily available tools and products you can use to speed this along

Getting Help

• Ideally, build everything yourself; it really helps your credibility and teaches you a hell of a lot along the way. If this isn’t an option for whatever reason,
• How to outsource the building of a prototype
• How to find a developer and/or designer
• Once the prototype is built and you’re happy, how to find the right rockstar lead developer to take it forward

I’d love to hear some feedback on this idea and information on areas you particularly want to learn more about (whether I included them or not) — and how you’d like to consume the information.

Cheers,
Jen

Disclaimer: I reserve the right to change my mind.

The Founder Institute’s Bay Area semester is coming up, and I initially started frothing at the mouth at the chance. After all, it’s opportunities like this which drove me to Silicon Valley in the first place… right?

Maybe not.

The Founder Institute’s programme looks fantastic. And very useful. Educational. Focusing. Intensive. An invaluable way for an entrepreneur to get a full picture of the business side of startups, the real driver behind the roadmap, etc.

It also looks extremely familiar.

In Edinburgh I have to admit I was a training junkie. I did EPIS, NESTA, the Ken Morse workshops, Ignite Cambridge, and Astia (UK and US). Plus some fantastic one-off sessions such as Bill Joos’ pitch training workshop which will undoubtedly be the reason I successfully raise capital.

But at some point, the wheels have to come off, and you gotta put all the training to work.

Reviewing the Founder Institute’s curriculum, there’s stuff in there I’ve seen time and again in the past. (Which is encouraging, rather than offputting.) There’s actually sessions missing that I think would be interesting, such as focusing on lean methods like customer development and metrics-based iteration, though a lot of it is common sense once you know the basic principles.

The main value of doing a programme like this one – especially this one, as it’s compatible with a day job – is forcing you to put aside time and focus on your startup, to make it a reality. And, primarily, the fantastic networking (and investment) opportunities. But, you know, I have those through Astia – and I haven’t used them yet, because I’m not ready to.

So, for me personally, the only real gain I might get from the Institute is a cofounder and mentor. I could definitely use a mentor, but there are ways to reach out to people that don’t involve a fee and equity, and a huge time commitment that I would rather not have right now.

So, dear Founder Institute, don’t take this the wrong way. It’s not you, it’s me. Maybe we can catch up in a year or so? Great. I’ll call you.

(Aside: If you’re not me, especially if you have a solid idea and little real exposure to the business side of things, you really should do the Founder Institute or something similar. It looks to be very useful, for the right person. And if you think I’m deranged and should change my mind, feel free to comment.)

Startup Weekend is an awesome concept. Strangers get together, pitch ideas, spontaneously form teams and by the end of a weekend have a working demo and pitch to show everyone else. As an attendee at last weekend’s Bay Area event, it was truly amazing to see the number of things built literally-from-nothing over 48 hours.

I’m a hacker-entrepreneur. I love to create ideas, turn them into business concepts, and then realise them in code. However, at Startup Weekend it seems the skillset of attendees can range from ‘just here for the ride’ to ‘hardcore $language programmer’ to ‘I love writing business plans’. Here are a few things I learned from the experience.

1. Pitch your own idea.

I didn’t. Then I remembered an idea I’d previously had about halfway through the weekend and was kicking myself for not pitching it. I definitely believed in the problem my team was solving, but I think there’s just a different energy level and focus, especially for me, when it’s your own idea. It would also have given me a better role to play during the weekend, that of leader/visionary/hole-filler/driver, rather than head-down hacker (which was a fun role to play, but I learnt over the weekend that it isn’t the role I enjoy most, any more.)

Even if you don’t get a team for your idea, pitching your own idea tells people a bit about who you are and why you’re there.

2. Pitch your problem, not your solution.

For both the kickoff night and the final presentations, the mantra ‘problem not solution‘ is key. Once the problem is clear, dive into the solution, but you gotta get buy-in on the whole reason you’re doing it. A few of the Friday night pitches asked the audience “How many of you…?”. Easy way to validate your problem and ditch the whole thing if nobody responds.

As the backchannel on Twitter said so clearly, if we don’t get it within 30 seconds, there’s something up.

3. For the love of god, don’t pitch something outside the scope of Startup Weekend.

I can’t believe how many people pitched existing companies (they were hiring, etc) or projects that were not Startup Weekend projects (here’s this thing I’ve previously built and I’ll drone on about it incomprehensibly). Whatever you already do, put it aside and embrace the creativity of 48 hours of collaboration.

4. Pick the team you can help most.

Friday night, picking a team, was tough for me. There were three teams whose ideas were pretty close, all problems I could sympathise with, and all ideas where my expertise could come in handy. I picked the team whose problem seemed the most in need of my speciality, where I thought I could make the most difference. Maybe this is just a cue to build a platform that I can license to all the teams…

5. Someone else will have the same idea.

One of the similar teams ended up pretty much building the exact same product idea as us over the weekend, which was quite amusing. Don’t sweat it. It just shows the problem you’re solving is real. If they do a better job, ask yourself why!

6. Don’t have too big a team. Especially if you lack technical direction.

We had six developers total, I think. Even now I’m not really sure what everyone did. We all used different platforms and languages, and nobody really understood how to put it all together. I didn’t even see working code from anyone else all weekend. Communications failure on my part, and role failure (nobody stepped up to be technical lead). I think we would probably have achieved a better, more-featured demo with only two developers both using the same platform.

7. Know what you’re being judged on and focus on it.

We also had a ton of business people, who contributed greatly to the business behind the idea – we had a business plan, I think we had financial projections, a twitter account, etc. The problem is that the weekend was being judged, almost entirely, on the strength of the idea and the potential of the solution. No time or reason to show slides on potential market cap, earnings in year 5, etc.

I think if you’re a business person, and you’re super awesome at financial models and market cap and P/E ratios and all that, and you want to contribute to Startup Weekend, you still can. Just don’t focus on one team and build out their investor deck when they haven’t even got a line of working code yet. Go around the teams and see if you can spend a few hours with a few different ones, helping them out. Or take on multiple roles for your team and man the twitter account, get some test users signed up, do some fake data entry, mock up some UI in Powerpoint, whatever. Make tea. Contribute. There’s a place for Excel, it just ain’t here.

8. Market research is awesome.

We sent out two surveys (one via askyourtargetmarket and one a Google Form) on the start of Saturday to validate part of the problem and get feedback on possible solutions. This process was really useful for streamlining some of the thinking higher-level, but we didn’t really have enough time to incorporate it fully.

9. Drink lots of water, not soda. Eat well. Sleep better.

There’s something appealing about staying up coding for 48 hours straight, but (especially if you have a day job to go back to the next day) looking after yourself is even more appealing. I put my survival through the weekend down to a lack of sugar, fat and general yuck. Too much pizza on offer, fortunately I couldn’t eat any of it.

10. Fail fast.

The advantage of prototyping and validating an idea in a weekend is the speed at which you can fail, and learn. If it isn’t going to fly, accept it and move on. You’ve ‘wasted’ a weekend, but there will be plenty of things you can re-use from the experience.

This is where the whole MVP/iterate thing comes in, too. If you’re not being lean, you won’t fail fast enough in the weekend to actually get something useful out of the experience.

11. Have funny pictures on your slide deck.

If all else fails, do an entertaining pitch at the end of the weekend and you’ll keep the fun factor high. (Bonus points if you do an entertaining pitch and seem to have built a working product!)

(Here’s another attendee’s take on lessons learned from Startup Weekend, too.)