Sean is a partner and product lead at Digital Intent, helping companies like Groupon, Follett, Sittercity and HarperCollins build and grow new digital products. He is also a Lecturer of Marketing in the Entrepreneurship and Innovation Program
at Northwestern's Kellogg School of Management.
Sean has experience in product development, user experience, user acquisition and analytics. He runs the Chicago growth hacking meetup, is a member of the Young Entrepreneurs Council, and writes about marketing on Technori.
Sean previously was the VP Product Development at Brill Street, where he was tasked with building an "eHarmony for jobs" algorithm-based candidate matching system. His team launched a beta in 3 months, and acquired 15,000 candidates in Chicago at $0.20 per in a 6 week period.
Prior to that Sean worked in New York at GoalQuest, a higher ed marketing startup, where Sean led product development of UPeers, a white label university social network that was implemented on over 300 campuses around the country. GoalQuest was acquired in 2007 by EducationDynamics, where Sean served as the VP Creative Director.
Sean has a degree in marketing from the University of Colorado. He's extremely pale.
Outsourcing is a great way to get your app faster without giving up ownership. Keep in mind the relationship likely won't end when you launch though - you'll want to plan for subsequent releases, as well as rapid optimization sprints as you hone in on P/M fit. You'll want to make sure you're comfortable working with that firm for an extended period of time. Don't spend your whole budget on the initial release.
It's also worth hiring a friend or respected dev to do a code review of any potential vendors. A common problem is outsourcing v1, bringing in a technical lead or cofounder, and finding out your code is in disarray and needs to be rebuilt. To the degree your app is leveraging native iOS elements that risk might be mitigated, and the disposition of the person you're bringing in is obviously a variable (some devs have "not invented here" mentality). But the peace of mind is worth the couple hours you'll pay for a capable code review up front.
One of our clients went with a card-based approach (http://purelyapp.com). The reasons were:
- People understand them. The separation and spacing lead to very little cognitive overhead.
- Perfect for responsive layouts, and translate easily to native mobile devices.
- Forces you to discriminate - you can't cram too much information in a card (at some point it ceases being a card), so it provides a nice constraint and keeps your product simpler.
- Easier to A/B test. Cards are a great example of what Andrew Chen has called an 'open system'. Many layouts are just loops of cards, which means making changes to a card object is trivial vs. changing the layout of a less modular, more structured page.
Hope that helps!