Archive for September 2009 -- Ken Yarmosh

Tweetie 2 – A Case Study in Making iPhone Apps Leaner

September 29, 2009

It’s really hard to make iPhone apps lean. With Apple’s walled garden (i.e., the App Store), it’s tough to both test applications and control the time between iterations. In the first case, there’s a way to do that – ad hoc distributions – but as any iPhone developer knows, it’s not very fun. In the second case, even when iterating quickly, there’s no way to know how long an update is going to sit in Apple’s approval queue. There’s more to discuss on making iPhone apps lean but for now, let’s move from the conceptual to the tactical and take a closer look at Loren Brichter’s Tweetie 2 announcement and how it will make his iPhone app more lean.

Background
Tweetie was first released on the iPhone back in November 2008. The core philosophy of it then, as it is now, was speed, simplicity, and the Apple way. Unlike many iPhone apps and particularly iPhone Twitter clients, Loren embraced what he described as the “iPhone interface philosophy” and thus did not re-invent the wheel for the UI elements. He believes his design choices were part of his success.

In April 2009, Bigbird, a new core architecture for the then impending Tweetie for Mac was announced. At that time, Loren wrote that Bigbird would become the foundation for Tweetie 2 for iPhone.

Of course, that leads us to the present. All the big blogs are a buzz about the upcoming release of Tweetie 2 for iPhone, including tantalizing screenshots. Those screenshots are what have blinded the pundits to the most important news of the release — the architectural changes and what they’ll mean for Tweetie going forward.

Architecture
Going back to making iPhone apps leans, two of the big issues are testing features both from a true feature standpoint (i.e., validating usefulness and effectiveness) and stability (i.e., does it work properly and not have bugs). Unlike in a web environment, there’s no real ability to A/B test and as mentioned before, performing quality assurance is a pain in the ad-hoc distribution. There’s a handful of ways to think about dealing with these issues — but let’s focus on how Tweetie did it.

1) Tweetie for Mac

Like TweetDeck (and soon EchoFon), Tweetie has an advantage over other Twitter iPhone clients — it has a desktop companion.

Now, not all iPhone apps can or should have a desktop counterpart. But those that do will reap the reward of tremendous learnings. While clearly an iPhone app versus desktop or Web-based app requires some different thinking, having a non-iPhone environment for A/B and QA testing features can allow a more proven app to go into the App Store. Especially when…

2) Synced Codebases

Loren will soon sync the Tweetie for Mac and Tweetie for iPhone codebases. He writes the following,

“Once I sync the codebase for Tweetie for Mac and Tweetie for iPhone, expect an explosion in functionality. I will be able to explore new features in Tweetie for Mac, pushing out updates there instantly, and once I’m confident that changes are stable, push updates to the iPhone.”

Tweetie’s unique advantage is that its desktop app is native to Mac. Unlike TweetDeck, which in all probability has to port many elements of its AIR-based app to the iPhone, Tweetie will have one core architecture powering both of its applications.

The key point, as he indicates, will be that Tweetie for Mac will become a test bed for Tweetie for iPhone. Once that occurs, Loren can quickly test different features across a much larger number of users, both for validation and QA, before incorporating them into Tweetie for iPhone.

Part of this testing will be facilitated by the fact that his architecture can “push out updates there [Tweetie for Mac] instantly.” Building his application this way seems to indicate that he is very interested and committed to trying out new features and learning what works best.

Concluding Thoughts
Ironically, it took the Tweetie applications nearly a year of what probably would fairly be described as non-agile development to make it more agile and lean. The last major update from Tweetie developer Loren Britcher was in April 2009, which means he has had his head down in development for about 4-5 months.

Although his initial reasoning for building Tweetie for Mac was likely not motivated for being able to test features, clearly that’s now a major benefit because of his new architecture and being based on the Mac platform.

The “Tweetie approach” can definitely serve as a model for making iPhone apps more lean. But it is a model. There are many cases where it wouldn’t make sense to have a counterpart or companion application on the desktop or Web. For those that do, having a native Mac application, even a stripped down MVP-style one, could go a long way towards making iPhone app development much leaner.

Starting Your Startup – Assessing Options

September 23, 2009

Building a business is hard. Ideas are a dime a dozen. Having an idea doesn’t mean much. Executing an idea and getting people to use a product you’ve built is a good first step. Actually having a paying customer is better. But that’s not the definition of success…it’s a foundation for success. You’ve got to continue to iterate and market a product to have any chance of eventually not joining the dead pool.

With the old adage that 9 out of 10 businesses fail within their first year, you’ve got to be smart with starting your startup. You need to have a realistic understanding of the size of your marketplace and fully grasp the risks associated with pursuing your idea. The decision to pursue your idea is not a simple “potential money > risks.” The goal in outlining your risks is not always to defeat them but instead to understand what you need to mitigate in order to have a better chance at winning the market.

Spending all your cash, as well as losing out on potential earnings are some of the biggest concerns for an entrepreneur starting any startup. A founder, if indeed a relatively competent one, can easily garner a comfortable salary at most companies. So, the cost of building a startup is not just any personal money that is invested into the company. It also needs to include the wages not earned.

There’s generally been two camps on how to deal with these types of issues. The 37signals perspective is that quitting a job to build a startup doesn’t deserve applause. They propose an organic, start small, and do it on the side approach. Others like Ryan Carson believe that entrepreneurs should launch a business and not a side project. Carson nicely outlines the go to market plans of most of today’s product companies:

1. Identifity a niche need that you have that’s currently under-served
2. Bang out somewireframes (or better yet, just start HTML’ing)
3. Ask a designer or developer to help out, in return for a bit of equity.
4. Tweet about an invite-only beta
5. Listen to beta feedback and make tweaks
6. Launch
7. Get TechCrunched
8. Build recurring revenue till you can quit your day job
9. Live the good life

While he fairly (and perhaps scarily) identifies the thinking of most entrepreneurs doing a side project, his outline equally applies to many who are working full-time on building a startup. In fact, even though many “building a business not a side project” startups have some sort of funding, their strategy and marketing plans often look the same as someone building a “side project.” Thus, this particular point does not support his argument.

For those that have compelling reasons to quit their day jobs or who require large amounts of capital to execute their idea, unless independently wealthy, raising money is a smart approach. Even though the present circumstances may allow entrepreneurs to choose whether or not they need VC investment, having money in the bank empowers entrepreneurs to focus more on building a business and less on how to pay their mortgages.

This leads back to both 37signals and Carson’s concluding point. The 37signals’ approach of not quitting a day job correlates to the security of VC investment – runway. By keeping a day job, there’s less, “oh no, how are my paying for my bills next month” moments. Critics would counter by saying that founders are less serious about their startups when those startups are not responsible for paying the bills. But if an entrepreneur doesn’t take his startup seriously as a side project with money in his pocket, why would he take it more seriously as a full-time endeavor with nothing in the bank?

As Carson writes in his concluding thoughts, and this point is important in linking these camps together, it may actually take more time post-launch than it did pre-launch to make a startup successful. The 37signals team spent a year on Basecamp as a side project before they could work on it full-time.

Provided that you are committed to your idea and particularly the post-launch activities, including product iteration, marketing, and advertising, it is hard to argue with the start small approach of 37signals. Today, there are also other frameworks like the lean startup and customer development, that all play to organic means of growing products and startups. Of course, this assumes that you aren’t starting off on the wrong foot by trying to build a dumb idea.

DC Tech and Startups – Ready to Breakout

September 21, 2009

I attended the DC edition of Startup2Startup this past Friday. The details of the event and the panelist are on Eventbrite.

All of the panelist had a focus on early stage investments and engaged with their companies as angels or incubators. Since the event was focused on the government, Errol Arkilic of the NSF had the most relevant experience understanding the way it operated and how his organization functioned more along the lines of the private sector. Errol was proud of being able to do deals in four months to Dave McClure’s surprise, where he stated something along the lines, “I might die in four months.” More details about the event are on the GOAP blog.

The difference in perspective between celebrating or cringing at the four month investment cycle might be marked by Mark Walsh’s observation of the modus operandi of DC and Silicon Valley,

“The difference between DC and Silicon Valley is inertia versus urgency.”

That comment holds true when generalizing the DC area to be represented by the mega bureaucratic federal government. In the context of the event, it makes perfect sense. But I feel that it reinforces a stereotype of those who live outside DC, one perpetuated even by the event itself, that the only interesting innovations for this region are related to Gov 2.0 and helping the government adapt the ideas and models of Silicon Valley.

Having spent time in Silicon Valley and previously living in New York, Boston, Philadelphia, and now DC since 2003, I could generalize each region, as DC is often generalized. There are typically truths in generalizations and stereotypes but they often purposefully and sometimes ignorantly miss the details to simplify or support a point.

Being in the weeds, I can tell you that innovation and entrepreneurship have been happening in DC well before Gov 2.0. It’s highlighted in the strength and success of groups/events like TECH cocktail (co-founded by local Frank Gruber), Ignite DC, Refresh DC, Twin Tech, The Capital Cabal, and Social Matchbox, as well as in people and companies getting recognition outside of this region. I believe the DC metro area is uniquely positioned to breakout from the pack and become an increasingly important area for startups and technology innovation…aside from Gov 2.0. Here’s why:

For those unfamiliar with this area of the U.S., read some background on what demographers consider the Washington Metropolitan Area. I’ll use “DC” to represent this region, which consists of parts of Maryland, Virginia (referred to as “Northern Virginia”), and Washington, D.C., due to their close proximity to one another.

DC has money. Five of the top ten highest income counties in the U.S. are in Virginia and Maryland, with three of those five in the top five. That’s mucho mula.
DC has talent. Georgetown, George Washington, University of Maryland, and American University represent the established well-known schools, while George Mason was recently selected by U.S. News and World Report as the nation’s top “Up-and-Coming School.”
DC has innovation. For the past five years, the DC metro area ranks as number six on the percent of startups distributed per state. LaunchBox Digital is a startup incubator program, much like Y Combinator, that just completed its second successful class of startups. The Northern Virginia Technology Council has 1,050 member companies and enterprises representing approximately 186,000 employees and is the largest technology council in the nation. And yes, we do have Gov 2.0.
DC has history. No, I’m not referring to the kind you find on the National Mall (that’s not a place for shopping, btw). Remember a little company called AOL? Maybe you are trying to forget about them or still using their CDs as coasters. No matter how you feel, they brought the Internet to the common man. Now, that was a world (or country) changing idea.

The growth in DC in the six years I’ve been here has been incredible. A massive project, which will continue to fuel this momentum, is the extension of the rail system to the Dulles Airport. The result will be easier access from the exurbs of Northern Virginia through DC proper and up into Maryland.

It’s an exciting time to live in this area. The foundations have been laid for DC to become a major center for entrepreneurship, startups, and innovation. Get in on the ground floor, or as close to it, while you still can.

The Best Advice to Entrepreneurs – Don’t Build a Dumb Idea

September 15, 2009

With all the advice for the TechCrunch50 floating around, here’s something entrepreneurs need to hear – don’t build something dumb.

I understand that founders put their blood, sweat, and tears into their companies so, I’m not trying to be cruel. In fact, I’m being kind by hopefully preventing them from wasting lots of time, effort, and money on an idea that will go nowhere.

The harsh reality is that some of the smartest entrepreneurs with the most innovative ideas fail for one reason or another (e.g., poor timing). Now, consider those chances for success when your foundation is a dumb idea.

You are wondering, “Am I building a dumb idea?” I am tempted to write a series of “You might be building a dumb idea if…,” but I think Jeff Foxworthy has that bit covered. So, here are some ways to prevent you from building dumb ideas:

Note: There’s a difference between dumb ideas and inane, gimmicky, childish, or immature ones that are well-executed. Consider some recent examples on the iPhone including iFart or most of Smule’s apps, which I’m sure have made boatloads of cash. Also, while “dumb” may be subjective, there are plenty of ideas where we collectively were left scratching our heads.

Build What You Know

An easy way to not build a dumb idea is to focus on a marketplace you know. While it is not absolutely required, industry expertise will ensure your product or service includes the “no brainers” while also smartly addressing complexities, details, and edge cases.

If you have an idea that is outside a particular area of knowledge, try to surround yourself or consult with those that are subject matter experts. For consumer-focused applications, that could be as easy as working with those who are using similar products or services.

Market Research and Filling a Gap

You can lessen the chance of building a dumb idea if you know your market and your (prospective) customers’ mindsets better than anyone else. That means not only knowing all the strengths and weaknesses of your competitors but also understanding complementary and alternative services or products. This approach is different than the first in that it might not be an industry that you have hands-on experience or intimate familiarity.

As I pointed to in my how to build a non-$0.99 iPhone app post, I’m a big fan of the blue ocean strategy. If you’ve never read the book, go buy a copy. The authors present a number of tools to help companies get out of the red waters of competition and into the blue oceans of new market space, including the strategy canvas and the four actions framework.

A key point of the blue ocean strategy is to look at competitors and non-competitors and customers and non-customers. This perspective allows the proper defining of the “factors of competition” for the strategy canvas and subsequently which factors need to be eliminated, reduced, created, or raised to plot the new value curve.

Consiglieri and Junto

While you can look to “insiders” to help validate your idea, don’t underestimate the importance of insights from consiglieri or members of your Junto.

You might remember the word “consigliere” from The Godfather, which means “counselor” or “advisor.” Having people you trust, and trust in the sense that they will give you sound, objective, non-ego stroking advice is critical to ensuring you don’t veer into the lands of dumb ideas. Your consiglieri (that’s the plural form) should likely not be your peers and preferably should consist of mentors, seasoned business execs, or startup veterans.

Benjamin Franklin initially created the Leather Apron Club, also called “Junto,” as a way to facilitate discussion among similar-spirited individuals about improving Philadelphia. It later evolved as a way for its members to to improve themselves and their community. A key element to the Junto was that the members had diverse professional backgrounds. Hopefully, you have a group of colleagues and friends — your “Junto” — that are outside your professional bubble, who can keep you grounded, in touch with reality, and provide alternate yet informed viewpoints. These people should be another sounding board for avoiding building a dumb idea.

Minimum Viable Product

According to Eric Ries, the goal of the minimum viable product (MVP) is to build a, “product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to gave you feedback on.”

Like how Tim Ferriss came up with the name of his bestseller The Four Hour Work Week, Eric describes how a landing page and a pay-per-click campaign can be used as a quick, barebones (and super cheap!) way to discover what products or product features customers are willing to purchase.

Customer Development Model

The Minimum Viable Product and the “lean startup” philosophy are based off of Steven Blank’s The Four Steps to the Epiphany. Professor Blank is in the midst of his series on the customer development manifesto, where he provides the background on why the traditional product development approach fails and what the customer development model is about (my emphasis):

The greatest risk in startups —and hence the greatest cause of failure—is not the technology risk of developing a product but in the risk of developing customers and markets. Startups don’t fail because they lack a product; they fail because they lack customers and a profitable business model. This alone should be a pretty good clue about what’s wrong with using the product development diagram as the sole guide to what a startup needs to be doing. Look at the Product Development model and you might wonder, “Where are the customers?”

The reality for most startups today is that the product development model focuses all their attention on activities that go on inside a company’s own building. While customer input may be a checkpoint or “gate” in the process, it doesn’t drive it.

Concluding Thoughts

These are just a handful of ways to check yourself before you wreck yourself. Do they ensure success and a huge exit? No. Will they absolutely prevent you from joining the dead pool? No. But they will work to prevent that by putting you on the path to success.

The Five-Minute Guide to iPhone App Market Sizing, Pricing Experiments, and User Trends

September 2, 2009

In both developing my own iPhone apps and in discussing with clients or prospective clients, understanding data and trends behind the App Store and apps is critical.

Jonathan Wegener provided a nice framework for market sizing. There’s also those in the community that have been kind enough to either due some homework or even share their own sales data. While the number of iPhone and iPod Touch devices continues to grow, meaning that this data will grow stale and less relevant over time, there is still much to glean from this information.

I’ve decided to share my synthesis of what iPhone developers and industry analysts have provided. The deck below quickly highlights information about users and apps, meaning there are details ranging from how users discover apps to the number of downloads it takes to get to the top of the App Store. It’s by no means exhaustive and is purposed to function more as a reference guide. I’m only cherry-picking the data I’ve found most relevant and interesting.

View more documents from kenyarmosh.

Ken Yarmosh – Product Strategist and Technology Connoisseur

Tweetie 2 – A Case Study in Making iPhone Apps Leaner

Starting Your Startup – Assessing Options

DC Tech and Startups – Ready to Breakout

The Best Advice to Entrepreneurs – Don’t Build a Dumb Idea

The Five-Minute Guide to iPhone App Market Sizing, Pricing Experiments, and User Trends

About Ken Yarmosh