We're happy to report that there's a new blog in town dedicated to promoting the Portland startup ecosystem: Stumptown Startups.
Stumptown Startups is run by local TV Station KATU News, and aims to "examine the growing startup scene in Portland and beyond." While the local tech and business press do a great job of covering the Portland startup scene, local broadcast networks haven't historically spent much time on the tech sector. If the news channels think this is worthy of their time, Portland startups must be getting closer to our goal of having a significant economic impact in Portland.
Stumptown Startups' first post spotlights Portland-based startup Simple, and we can't wait to see what's next. Props to KATU and reporter Erica Nochlin for giving Portland's startups some well-deserved attention.
I spend a lot of time explaining the Upstart Labs model to people I meet. Our portfolio is small – just seven companies to date – and you won’t see us packing an auditorium for a demo day twice a year. As an early-stage investment fund, we’re more likely to be found behind the scenes than introducing our latest crop of companies.
Upstart Labs is different because we invest in the form of professional services rather than cash. We provide access to a team of 13 – developers, designers, project management, marketing, business development and sales – in addition to mentoring from our executive team and business services such as legal and accounting. Rather than giving startups a pile of cash and waiting for them to hire employees, our portfolio companies hit the ground running on Day One.
When pitching investors, startup founders try to cut right to the chase with their “ask” – how much money they need, and what, specifically, they’re going to use that money for. One of my favorite things about the model that we’ve established at Upstart Labs is that it gives founders the ability to modify the specifics of that “ask” during their time with us, as conditions dictate.
Hiring employees is expensive; hiring creative and development agencies is even more so. We’ve heard angels complain that a quarter of their investment (or more) is “wasted” by startups on contractors and other pricey purchases. Companies in our program avoid those expenditures during their tenure, and get more time to refine their model – and generate revenue! – before pulling the trigger on long-term expenses.
Our team augments a startup’s existing team. With our team’s help, companies in our portfolio who have products in the market can expand their features, add platforms and services, and enter new markets. We’re investing in this way – services first – because we believe it works. Need more evidence? Just read what our Upstarts say about us.
We're always looking for our next success. Here's a quick way to learn more about who we invest in and how we do it, and how you can apply to our program.
When your startup vision is big — a suite of apps used by hundreds of millions, funded by a couple rounds of financing — it’s easy to think of an App Store launch as a small step along that road. If you hear people claiming that they can build Instagram in a week, what they’re probably thinking is that they could assemble a prototype that approximates the idea. And, undoubtedly, a talented iOS dev working from the fully-formed idea of Instagram today could be feeding captured photo data through some CI filters, uploading it to a server, and pushing it to her social streams before the weekend. If there weren’t any stylish mobile photo-sharing apps out there and I’d had the foresight of that premise, I’d be off prototyping it right now.
Products with focused feature sets tend to seduce us into thinking that success is a matter of hacking on our idea for a week. The nature of mobile UIs makes this seem all the more reasonable. But strong implementations of good ideas always tend to feel within reach, and there are reasons that 900 million people aren’t using any number of Facebook competitors to manage their personal lives.
So: we could assemble our team to build and polish our vision, and if we’re lucky enough to have Instagram-in-a-week-caliber people, then maybe we’ll be able to get our own untested idea to market in a few months. Or we can try to test our assumptions with prototypes, knowing that if we build out the whole thing and then try to iterate, our v2 might mean starting from scratch. I’ll try to explain why we think this is usually the right approach for a startup.
Iterate with prototypes
Sketches, wireframes, design comps, and interactive prototypes are all steps in our process. None can assure that our idea will work in the end: carefully-crafted wireframes need re-thinking once we see them implemented with our designer’s graphics; beautifully rendered layer comps of a list-sorting UI seem perfect until we actually use it on a tablet. We can only hope to find the problems that will keep the project from succeeding.
Put another way, our goal with the prototype isn’t to prove-by-wireframe that the product will be just what users want. Instead, we’ll hypothesize about the ways in which the product will fail and try to find the potential failure points as quickly as possible so that we can work around them. Think of it as a loose relative to reductio ad absurdum: let’s try to convince ourselves that the product won’t work as we’ve designed it; if we can’t, then maybe we’re on to something.
We’ll either get to the right product a lot faster, or learn some important lessons and move on to the next idea. This is true even when we’re totally confident in a product idea. And it’s true whether we’re spending evenings hacking in a coffee shop or have millions in funding because if nothing else, failing slowly carries an opportunity cost. We prefer to uncover our misguided design assumptions, missing features, and broken interactions as soon as possible. We’re sculptors starting our implementations with sketches and clay.
Prototypes as user testing
As a developer, I lean heavily on interactive prototypes, which may or may not implement the designs from our creative team. It’s generally easy for us to build a quick mobile web demo, or a storyboarded iOS app, or even just a set of comped images with gesture recognizers to simulate a user experience.† Prototypes like these give us the opportunity to learn, relatively cheaply, that the idea isn't right — and to make needed changes early in the process.
The kinds of prototypes I’m hinting at here are for user experiences. We work from a set of user stories and use the prototype to improve them. Along the way, we discover that features we thought critical are marginal or unnecessary; we uncover functionality we didn’t know we needed; and we’ll almost certainly find a better way to design part of the interface.
Of course, UX is rarely the whole story. If you’re a technical entrepreneur, you’re already writing spike solutions, integration tests, or other proofs of your core concept. The good news, if it’s not obvious, is that these two kinds of prototypes can be built in parallel by different teams. There’s no reason we shouldn’t iterate on the interface of a multi-player mobile game at the same time we write our API integrations and test for network problems in target areas.
The faster you can find those failure points, the better
At a talk at Urban Airship last year, Eric Ries quipped that after months iterating on a product and only then discovering that not a single user was interested in downloading it, the only thing they needed to build was a marketing page with a download link that 404'd.
Start on that end of the spectrum: focus on the biggest questions first and build as little as possible. The next step is always a slightly more-realized product; the next step is just your next iteration.
† There are dozens of tools and techniques for prototyping, and perhaps I’ll talk about some of those in a future post.