Focus

Editor's Notes

1. title slide, no talking points\n
2. My name is Jim Snodgrass. i’ll give a real quick overview of what i’ve done leading up to now. I started out working in the restaurant business doing everything from serving to management, quickly decided it was too much work so I moved into more technical fields and use my brain more (I started learning HTML @1998, and was always the guy who fixed everyone else’s computers). \n\nSo i got A+ certified and started finding contract jobs. I started out doing everything from running cabling for data centers, implementing large Palm Pilot migrations, to hands on tech support. I landed in a large hospital system in Columbus, OH where I started during a project to migrate @6ooo desktop devices to Windows XP. I then went into their tech support department. After a couple years of that and doing development in my spare time, a friend got me to interview for a position and I got a job in their Application Development department. I stayed there for @3 years before moving here to NC to work at Skookum. so, who am I now?\n
3. going to start off by showing a few examples of products that focused either very well, or very poorly during their development time\n
4. here we have Draw Something.\n\nbought by Zynga for $180 million. They are still working on lots of requested features, but now have lots of money and feedback to help implement them.\n
5. 1st generation iPad\ncame after many failed tablet PC attempts ,mostly using windows CE and trying to be a mini PC\n“who’s gonna want that, its just a big iPhone”\ntheir focus was, an excellent device for consuming content (mostly online) and an app platform \n
6. 1: Jaguar Controller\n2: original fat XBOX controller\n3: Sega Activator (octagon sensor on floor using infra red beams to detect movement)\n
7. this is how the dictionary defined focus. notice the word “center”. that is an important concept, because all the ideas we have for our apps are huge, we have to find that center key aspect that holds everything else together. the one thing, that if it stopped working makes the app non existent.\n
8. these 3 question are really important to keep in mind whenever deciding what to do next\n
9. this is your core. you should be able to describe this in a very concise way. this shouldn’t be a list of all that it does. Google, for example, is a search engine. They do lots of other things now including more features in the search itself. They got to where they are, though, by concentrating on being the best search engine.\n
10. this is your target audience, the people who are going to interact with your product. this includes ideas like personas, which are very powerful tools that I don’t see getting used near as much as they should. this is a question that should have a more detailed answer with as much information about this person as possible. everything you do should go through the filter of, “will this person find this useful and will it enhance their core use of the product”\n
11. this can be many things. this could be the same person as the last question if you expect that person to buy your product. it could that person’s parents if the product is targeted at children. if we talk about software, it could be from advertisers. if you’re looking for investors, this is an extremely important question to keep in mind.\n
12. so those were some over arching questions to keep in mind throughout the life of your product and ones to define well before even starting to develop the product.\n\nNow I’ll go over some general ideas that I like to keep in mind when deciding which features to implement next.\n
13. in the first of the 3 core questions, I said you had to concisely define what it is your product does. so, what I’m saying here is to make sure, especially in the beginning, that you really focus on that core functionality. everything moving forward depends on these aspects being rock solid. when I say tested, i refer to many types of tests including user testing and programatic testing. everything from the UX to the technical architecture should be as close as you can get to perfect. everything you add from there is going to degrade the experience in some way, so it’s really imperative that the core is awesome. if at any point you feel that the core has become compromised, step back immediately from anything new your adding and address it.\n
14. as Hunter Loftis likes to say, “code is a liability”. I would add to that it is also expensive. the more features and add-ons that get added, the more expensive everything is moving forward. by sticking with the core and really refining it, you add less code and spend less money developing the product.\n
15. when you show someone your product for the first time, the first thing they will almost always say is, “wouldn’t it be cool if it did this?” you really have to show restraint, especially when it seems that it would be easy to add in real quick, to not jump on every one-off request you hear. this is especially difficult when it comes to investors. you think, “hey if I add that feature they want, they’ll give me money!” this usually ends up having the opposite effect, as the investor realizes that you obviously don’t have a clear plan for the product and are just trying to please everyone. if you want to impress the investor, spend more time refining question #3, where will my profit come from. that’s what they really care about, not if they’ll buy your product, but if you know other people that will.\n
16. this is a really enticing black hole that developers, especially good ones, can get caught up in. this is also what doomed the power glove. instead of focusing on what people will want to use and what supports the core vision of your product, you bog it down with cool features that may demo well but don’t really get people to pay money for it. this also goes back to code being a liability. each of these cool features adds code and cost to the project and another thing to make sure doesn’t break down the road.\n
17. this tacks on where I was going with the last slide, everything you add or change affects something else. if it’s part of your core, it likely affects a lot of other things. this means that the larger and more complicated the product gets, the more expensive it is to change anything, especially core functionality that maybe wasn’t tested or researched well enough in the beginning.\n
18. I’ll give a quick demo of a little app I’m playing with, we call it Quarry, that I hope will help people define those core features and especially the ones that are highly depended on.\n
19. here are a few links that have lots of information about this topic.\n