The Lean Product Life Cycle

See my previous post to understand how I got here. The hypothesis is that product development is messy except for the most disciplined. After talking to a number of great product people, I have a theory for how great product can be developed while being customer centric (aka lean).

The Virtuous Cycle of Lean Product Development

The Product Management Funnel

I think of product management as a funnel. At the top are all of the ideas your team generates. If you’re a lean startup, that’s hopefully driven by customer interviews, website and landing page behaviors and support interactions and of course the occasional green space wild idea.

As product manager, this is the most dangerous step. Once you have more than a few employees, it’s easy to have these ideas overflowing and interfering with the whole product process. Multiple teams I spoke with have been using their project management tools to capture these ideas which leads to a huge mess (one such company had over 4,000 stories in their icebox!) and a major time suck (one vp of engineering is spending an hour + each day managing these ideas).

The problem is project management != product management. The only thing that should be in your project management tool are key bugs to fix and what you’re building now or in the very near future (ie next sprint). Everything should be clearly defined and in a language and structure preferred by your engineers. All the evolution of the product from idea to customer validation to final prioritization should be done outside the project management tool.

The Rest of the Funnel

The Full Product Funnel

Going back to the beginning, you need discipline at the top of the funnel; the best product people I spoke with are requiring a shred of data tied to an idea to make it into their coveted ideas list. They also often expect a disciplined approach to what goes in by having people state, “Feature X will move Metric Y by Amount Z” so it’s clear why the feature needs added. In earlier stages that may be in a “Hypothesis vs. Metric to Invalidate” format instead.

The key of this step is effectively managing the signal to noise ratio; for every 5-10 ideas that come in, you may only make 1 or 2. Even the less disciplined product managers I spoke with have some type of hot-lukewarm-cold system for trying to rank ideas. To avoid the 4,000 stories in your icebox (or anywhere else) you have to be disciplined on dropping stale ideas and focusing on what matters now. When you’re a growing startup, where you were 3 months ago is dramatically different from where you are now so why keep those stories cluttering your system now?

After wrangling the initial feeder of ideas under control, you need to effectively refine the ideas that make it into your system and allow the most important ones to rise to the top of your list. As planning for your next sprint begins, you need to prioritize these ideas and balance with other existing projects, bugs and other demands.

Once you’ve settled on what you’re going to have engineering build next, you need to engage your team on the ideas you want to implement; you may need copy from marketing, stories from support to describe customer complaints, links or screenshots from analytics to show present activity and relevant customer development notes. All of this feeds into the project management tool you have, but now it’s uncluttered and your engineers are much happier and efficient. Unless you’re github or heroku, chances are your engineers don’t understand the customer they’re building for perfectly so all this structure makes it easier for them to see what’s going on and then adapt it to fit the project management tool they’re using to track building.

As an added bonus, there’s transparency for your other employees as they engage in more than just the initial ideation process. It also means sprint planning no longer needs to have all hands at it as they’re already well aware of what’s going on and have had opportunities to contribute as needed to the stories now being generated in the project management tool.

Completing the Virtuous Cycle

We all know this image so well as the core of what lean startups is all about, but how often is this cycle cleanly implemented? The project management tools out today all do a great job on the build aspect, but what about measure and learn?

The funnel process I described above captures the learn aspect as you engage your team for ideas and validation. All that’s left now is to measure.

After you build something new in your project management tool, your engineers will submit it for some form of approval. Once approved, it universally ends up disappearing into the ether, because the project management tool is built to track what you are building or about to build. After building isn’t part of their process.

To close the lean loop, you need to look back and see if that feature actually moved the needle. This needs to happen within 2-4 weeks of building it; sooner wouldn’t be enough data and longer would be distorted due to other things you’ve likely built by then. This last step of learning should help you refine your instincts and feed back into what you build. This is one of the biggest challenges as Eric discusses his principle of Innovation Accounting in his book.

The amazing thing I discovered in so many of my interviews was how rare it was to do this measure step; how can you improve your accuracy without seeing if you hit the target?

The Product – Lean Opportunity

What started as an investigation of lean startup opportunities has broadened to helping teams close the loop in managing a product lifecycle. I believe there is tremendous opportunity to build a platform to aide on both sides of the project management tool and much wider than those adopting lean concepts officially (as we all know, being customer centric is not a new concept).

 

Using Customer Development on the Customer Development Process

Earlier in November, I started out on a journey to see if there was an opportunity to build a product that would help companies in being a lean startup. The thought was that with Eric Ries’s book flying off the shelves and the lean startup community exploding, there would be new problems to be solved. Thanks to a nudge from Sim Simeonov and a few consulting opportunities brought my way, I felt like there was definitely something there. Like any startup, once I got outside the building, I learned some harsh realities:

1) Most people only pay lip service to lean.

Painful, but true. In both casual conversations in our community and full blown custdev interviews I found the full spectrum from strict implementers like John Prendergast and Matt Mamet (coincidentally co organizers of the local Lean Startup Circle Boston) to people who claim to be lean and think it has anything to do with how little money they spend (names withheld to protect the innocent).

2) Lean is a hands on activity.

The key to lean really is the human interaction; knowing when to ask an interviewee “tell me more” or deciding what analytics to deep dive to match up against your anecdotal discussions can’t be productized directly. It’s also risky to outsource since it’s so core to the future of your business; no amount of meetings, notes and summaries can compare to being there and doing it yourself. There’s huge opportunities to teach companies how to become lean, but I’m passionate about building a product, not a services business and I’m not sure most companies are ready to invest in lean (see 1).

3) Small startups are more likely to be lean and less likely to need process.

Part of the challenge of the adoption curve of lean is that it has most strongly permeated the zero stage entrepreneurs; they’re the ones with time and motivation to watch the videos, read the books and stay up on all the blogs (which has come a long way in the last year or two since all we had was the Four Steps to the Epiphany to go on).

Unfortunately, those people have little to no budget and because of only having a few people on their team, there isn’t much of a need for tools. Everything can be done ad hoc when you’re that small. The most common behavior when you have 5 or less people is to remove your headphones during the work day and share your findings immediately with everyone on your team.  This is effective until you grow to the point that everyone doesn’t know everything that everyone is doing (usually around 8-15 people).

So all that meant to me was time to pivot:

I’ve known all along that customer development feeds into product management. Fittingly, this is where I did find pain:

  • Managing product while being a growing, lean startup requires significant discipline. Not all companies have product leaders with this strength.
  • Many companies build up product management debt as they grow and fail to adapt to the demands of a team that passes the “take off your headphones and talk” phase.
  • Multiple challenges arise in engaging all members of a company at the right times in the right way.

My next post explains what I’ve found. Read on to see the big picture potential for a lean focused product life cycle.

Continuous Deployment: Possibility or Pipe Dream?

For those in the Lean Startup world, the utopian version of product development is continuous deployment.  It means every engineer is deploying code multiple times a day, often even on someone’s first day of work.  It’s also exceptionally test driven, reducing risks of bugs taking down the entire system.  While many startups aspire to this, few have succeeded, which is why it was so exciting to have Brett Durrett of IMVU come and speak to the Lean Startup Circle Boston Thursday night.  Brett is VP of Engineering at IMVU, which coincidentally happens to be Lean Startup Guru, Eric Ries’s startup he spent many years helping build before becoming the movement’s biggest evangelist.

{Note: Brett’s presentation was awesome but hasn’t been posted yet. I’m embedding his Lean LA version as a reference until it can be posted.}

Continuous Deployment at Lean LA

View more presentations from Brett Durrett

In a nutshell, continuous deployment breaks down into 3 steps:

  1. Develop a feature
  2. Test it
  3. Deploy it

But why would you do continuous deployment?

The reason for using continuous deployment hits the core of lean startups: more iterations. Whether funded or bootstrapped, there’s a limited amount of time to iterate and nothing speeds iteration like getting new features, site tweaks and updates out faster. Continuous deployment forces you to break down all your features into bite size chunks which can save you building massive features when you can confirm it with much smaller steps. It also minimizes version control issues if no one is working on a long term project based on old code.

It also makes your engineers more efficient. Is it easier to find the problem with freshly deployed code that has 10,000 lines in it or 10 lines? Is it easier to get engineers up to speed on a system that expects them to write a micro feature or build a major piece of the system?  If everyone writes their own test code, you have greater accountability across the entire engineering team (you have to fix what you break) and you don’t have to hire a QA team stuck cleaning up everyone else’s mess.

The Continuous Deployment Process for Engineers at IMVU

After convincing us why it matters, Brett walked us through the process for an IMVU engineer.  Once an engineer has finished building their bite size feature, they walk through all of the following in less than 15 minutes!

1) Engineer runs the test in their sandbox.

To keep from clogging the deployment and testing systems everyone shares, engineers first run some basic PHP tests on their own system to ensure the code is ready.  (Note: they don’t do branches in the repository; the brand in the code instead.)

2) Engineer runs testing on main system

After passing the tests on their computers, they enter the queue for the main testing system for all over IMVU called Buildbot. They have tons of tests so you tag your code based on what parts of the system it affects and what it’s for. This optimizes the right tests to run and which can be avoided. (Running every test would take over 8 hours.)

On average, it takes about 8 minutes to run all the tests needed.  They’ve achieved this speed because they have 40-50 instances running just for testing.  They’ve also discovered that 12 minutes or less is the optimal time to have testing take and keep your engineers happy.

The most common slip at this stage is a missing tag, which means a needed test isn’t run.

3A) If all tests pass, the engineer now deploys the code. 

3B) If any of the tests fail, the engineer reverses their commit.

With the rate the whole team is deploying and testing, their’s no time to have people fixing while they’re in the system. Therefore, regardless of the issue, the engineer will reverse their commit and go back to fixing the problem on their machine and starting the test and deploy process from the beginning.

4) Deployment occurs in pieces

Currently, IMVU (with over 50 Million registered members) has 800 servers in use.  When they deploy new code, it starts out on just 35 servers. This ensures that if something goes wrong, it doesn’t take the entire site down.

5) Testing continues after deployment thanks to the Cluster Immune System

Even after deployment, they’re still testing, just in a different fashion. They’ve developed their own tool called the “Cluster Immune System” which monitors key site (speed, system performance, etc) and customer metrics (revenue, registrations, etc) to make sure there hasn’t been a dramatic change.  Even the best tests won’t notice an engineer accidentally made a blue button on a blue page; the tests will see the button is still there and works, but won’t realize a user can’t see the critical sign up button.

This system runs on those 35 servers they use as a live test bed. If anything goes wrong there, they prevent it from deploying to the rest of the system. If not, it’s deployed system wide to all 800 servers.

An audience member asked about “what if you don’t have massive traffic you can segment to test a new deploy?” Brett said it’s an advantage when you’re bigger, but until then, you may just run at Cluster Immune System to monitor a system-wide deploy.

The best news of all of this?  IMVU plans to open source the Cluster Immune System (CIS) soon.

6) If all CIS testing is passed, deploy to all servers, but continue monitoring

Even after deploying to all servers, they still monitor for anything unexpected. If they see anything alarming, they’ll roll back and remove the feature.

This entire process takes only 10-12 minutes.  Only one engineer can be in the Buildbot testing phase at a time, but as soon as you enter deployment (step 4, above) someone else can enter buildbot.

This process sounds great, right? But it seems so sophisticated…how do you get started? Brett covered that too..

Getting Started – How do you actually do this?!?

Getting started is a different process depending on if you’re an established company or just an infant startup with limited traffic, but either way, there’s great ways to get started:

  1. If you’re a small startup – Start with a sandbox for each of your engineers and just focus on pushing code quickly and in small chunks.  You can develop your testing as things break; that’s how IMVU built their system.
  2. If you’re an established company – Start with production (ie- the last step before deploying code) and automate that process. Start building tests for whether something should be deployed or not.  Work to get the automated tests as good as the human part of the process. Once you’ve accomplished this, keep working backward to continue to remove humans from the deployment flow.  At first, you should err on the side of preventing problems then clean up your tests to be efficient.

Whether big or small, the same key rule applies: Anything can break once. Then you have to make it so the same thing can’t happen again by writing a test for your mistake. This builds both accountability and builds only the tests you really need…one step at a time.

Pitfalls

Like any system, this isn’t perfect. There are challenges both with getting personnel buy in and in scaling this:

1) Philosophy- Blameless systems

It’s not “Ned broke this!” it’s “How did we let that fail get through our system.”  Brett really emphasized this important difference. It’s a philosophical buy in required to really make this work best.

At IMVU, they hold regular “Blameless Post Mortems” to discuss issues that slipped through.

2) Optimize your testing

As you grow, more tests will be required. You should optimize for which tests actually need to be run for a specific line of code (as they did with tagging) and purchase sufficient hardward to make tests fast. IMVU also found they could save a tremendous amount of time simply by optimizing the order the tests run, by running the slower ones first (a 22% time saving).  They also then built in dependency in the testing (ie- if Test B requires you pass Test A to work…make sure Test B runs second).  Finally, sandbox testing of high level issues kept a lot of code from entering their “1 engineer at a time” test system by having everyone be able to test it on their own machines first.

3) Outsourcing doesn’t work well

This sort of system requires a cultural buy in that IMVU found couldn’t be instilled well remotely. It also proved difficult to manage the testing system whenever some engineers were in a different time zone.

4) Complex fails are harder to find

Brett still occasionally finds issues don’t fail during the work day…and being VP of engineering it means he gets the 3am calls about such issues.  They also struggle with MySQL and memcached issues, which has led to separate systems being developed to deal with them.

The key principle in all of this is that continuous deployment is a constantly evolving system. It is not perfect. However, taking it one step at a time will help you build a formidable engineering process that allows your company to move faster than you ever thought possible.

Ready to try to bring continuous deployment to your startup?

Lessons learned in getting press

This post originally appeared on Greenhorn Connect here: https://greenhornconnect.com/blog/lessons-learned

I’ve been very fortunate over the past few months to get some really awesome press coverage for myself and Greenhorn Connect.  I also worked at a startup where the CEO was extremely adept at garnering press as well. From these combined experiences, I’ve learned a bit about getting press. I’d like to share some of those lessons here and hope you’ll leave any lessons you have in the comments.

Lessons learned in getting press

1) Press comes in waves

When I joined oneforty in April 2010, Laura was making waves as she helped cool the Twitter developer community that was upset by the acquisition of Tweetie, the first of many ecosystem upsetting acquisitions. The coverage around the meeting Laura helped organize for the major apps and Twitter led to a ton of additional stories across the blogosphere and press. As I stood amazed at the press coverage, Laura told me the wise words, “Press comes in waves.”

Now that I’ve seen it first hand, it makes complete sense. My part in the Scott Kirsner Sunday Globe article on keeping young talent in Boston led to Boston Magazine deciding to cover me as a Person of Interest.  Curt Nickish, who wrote the Boston Magazine article was then able to spin the piece into a second entry, this time with a slightly edgier tone and a wider audience in Fast Company.  I expect this is the end of it, but who knows.

From talking to friends with PR experience, I’ve learned that you can also try to intentionally create waves.  By strategically pitching different journalists different aspects of your story at varied times, you can create a similar wave of stories about you and your business.  Do this a few times and the relationships you develop will allow you to make serious waves around big news for your business.

2) Everyone has an angle

In many ways the two stories I had were the same story, just told very differently.  It speaks to the different audiences of Boston Magazine and Fast Company; the former is affluent New Englanders, while the latter is a widely distributed, national publication focused on business with a slight edge. To affluent New Englanders, the story is interesting because I’m a young guy making it in Boston. To the wider population of Fast Company, the story became more about the rise to “power” the article implied I have over our community (Obviously no one has “power” over our community, certainly not me).

On the flip side, you can use this to your advantage when trying to be written about by doing your homework. Research the journalist and pitch the story in a way that you believe would be most compelling to them. You can also check sites like Help a Reporter Out (HARO) for opportunities.

3) Control how you’re perceived

If you’ve been following the TechStars TV drama, you’ll notice that what was pitched as a documentary has actually been a by the book reality TV show complete with jocks, overconfident teams and many perceived winners and losers. Hacker News was ablaze the other day over a blog post by Melanie of ToVieFor.  The companies on the show are lucky, as according to Jason Baptiste, TechStars fought hard to tone down the reality-tv bent of the show.

When they called me for the photoshoot for the Fast Company article, they suggested they photograph me wearing a crown and handing out crowns to other people walking by. I rejected this idea flatly, as I think that image combined with their original proposed headline, “King Maker” would have made me look pretty silly at best and a total ego maniac at worst.  Fortunately, I was able to get them to go with a more conservative photo as you see me shaking hands in the article.  If I hadn’t spoken up, no one else would have for me and I’d be the one looking like a fool.

Don’t be afraid to be proactive. In the future, I plan to request the right to read the article before print when it’s more than a simple news story .  If you get major press coverage, what is written can be a the first impression of you to many people.  Press is cool, but you want to make sure it’s something you and your friends/coworkers/staff/family can be proud of.

4) The truth always wins out

If you only knew Jason Baptiste from TechStarsTV, you’d think he’s a cocky, overconfident startup kid.  If you’ve ever read his blog, asked a question of him on Formspring or met him in person, you’ll know he’s a very down to earth, smart guy that really cares about building a great company and helping others when he can…and happens to have a flair for theatrics in presentations.

If you think you have a communication crisis, lean on your friends in PR; they’ll know what to do. People appreciate honesty and transparency. Just look at how Grasshopper handled their Chargify issues or how Theo Epstein made the most of an ugly Red Sox breakup.

5) Journalism is about relationships

Many in Boston were in awe at how easy Laura made it look to get major press for oneforty on a regular basis.  The answer was not that we had a killer PR firm (we had none). It was that Laura built relationships with tons of journalists. During those trips to the Valley Laura periodically took especially early in the days of oneforty, she wasn’t just raising money; she was also building relationships with the tech press out there. Not surprisingly, the same person she was having beers, coffee or meals with were then more likely to write about her.

When I met with Curt for the Boston Magazine article, we ended up meeting much longer than expected and having a conversation that went well beyond an interview and allowed me to learn a bit about Curt as well.  I believe it was this reporte and the mutual respect we developed that Sunday afternoon that contributed to his motivation to try to get wider publication of my story in Fast Company.

Like so many things in startup life, I feel like I’m just learning the tip of the iceberg of what I need to know and master.  If you’ve learned any lessons in PR and media, please share them for all of us to learn!

Leadership Lessons First Time Entrepreneurs Forget

While building Greenhorn Connect, I’ve spent a great deal of my time with young and first time entrepreneurs.  If there’s one thing I’ve come to appreciate, it’s the absurd odds stacked against any of us succeeding; there’s just so much that you have no idea about and need to quickly learn.

You could spend years learning just one small subsection of your duties like SEO, analytics, customer development, copywriting, design, fundraising, product development, development architecture or simply great coding, but the demands of startups says you need to become competent and relatively adept at all of those and more.  Amongst all those hard skills, I didn’t even mention leadership, which I think is the most underrated skill to develop as a young entrepreneur.

Leadership is a bit different, because it’s a soft skill; it’s not as easy to measure as the success of your marketing campaign or the elegance and functionality of your code.  However, it’s an immensely important skill and one with more long term value than becoming an expert in any one of the aforementioned hard skill areas; if your goal is to build a company with more than yourself as an employee, then you’re going to be leading others.  As you grow, you’ll be leading more people and spending less time on any of the individual skills you used in the early days and much more on communication, vision and goal setting and coordination across teams.

As I’ve learned through my own errors and in talking to other young entrepreneurs, I’ve noticed there are 2 major concepts most of us don’t recognize that are absolutely critical to leading your team even when you only have one or two employees:

1) Your employees don’t work for you; You serve them.

Having employees means that you’ve been able to convince others to work with you on your idea.  Appreciate the incredible feat that it is.

However, do not think that because they work for you that they are now enlisted to your dictatorship. You need to involve them in core discussions, listen to their ideas and feedback and cultivate a culture of appreciation and shared passion.   A happy, engaged employee is 5x as productive as a frustrated, stymied or sad employee.  This ebbs and flows, so you really need to watch for it on a daily basis.

Showing appreciation for those that work for with you is not optional; you cannot over-recognize their best efforts.  At the same time, it is a balancing act.  There are times for the carrot and other times it is best to lead them with a stick.  Each employee will respond differently, so it’s a skill that requires fine tuning for everyone you work with.   Personally, as much as I love a good reward, I value constructive criticism significantly more; I’d much rather hear how I can do even better next time than dwell on what went right. Unfortunately, what I, you, or anyone else prefer is completely different than the next person you hire.

I constantly feel humbled by the fact that I have a team helping me make Greenhorn Connect a success today.  I do everything I can to make sure Pardees and Ian know that and have learned well the power of having excited, motivated people helping you fulfill your vision. An hour spent cultivating your employees will pay you back exponentially.

2) Uncover and fix problems when they’re small.

With all the hustle and constant activity buzzing around a startup, it’s easy to overlook small problems. Don’t.

When problems are small, solutions are small as well. When problems grow up, then it takes big, dramatic solutions to overcome them. If it’s an interpersonal issue or a major team issue, then suddenly that small issue can lead to someone having to be let go.

Catch problems when they’re small by reading your employees;  look at their face and posture, and if an employee seems down or upset…asking them if something is up and if you can help has huge immediate and long term benefits.

Conflicts and small issues are often simple misunderstandings or honest mistakes. Tackling them head on breeds a culture of accountability and openness to healthy criticism.  When you get your team in this habit, it becomes much easier to avoid major problems, because they never get that big.  Having a discussion about firing someone is a much more dramatic discussion than talking to an employee about a minor issue that may have caused conflict or hurt the company.  Nip problems in the bud and encourage your employees to do so as well.

This post may seem like stating the obvious, but theory and practice are two very different things.  Just like hard skills require practice and active use to become sharper, leadership skills like the issues above require active diligence to become adept at them. Ask yourself how your team is doing at managing these issues; I bet there’s times you’ve noticed your team’s mood affected productivity or a problem grew larger than it should have and caused trouble.

Have you learned these lessons the hard way? What key leadership skills do you think first time entrepreneurs need most?

Lessons Learned from Observing the OnSwipe Investment Announcement

I really enjoyed seeing the explosion of stuff for local Jason Baptiste and his startup OnSwipe. To really see how this all works, you need to read all the articles surrounding the events of the last 24 hours:

This morning:

TechStars NYC Announces their companies in their first class with one Mystery company:

BostInnovation: “NYC TechStars Companies Announced”

note the allusion: “And a mystery company focused on building a “Platform for Tablet Publishing and Advertising.”  I immediately thought of PadPressed (the old name for OnSwipe) for a lot of reasons I won’t go into, but couldn’t figure out why they wouldn’t be announced.  Then it was cleared up…

Tonight:

1) TechCrunch Announces the Funding:

OnSwipe Raises, Like, A Million Dollars

2) Jason’s take on the OnSwipe Blog:

“The Road Ahead: Why Tablet Publishing Is Transforming The Way We Consume Media”

3) And Boston Angel Wayne Chang talks about his investment in OnSwipe:

“Proud To Be a Part of OnSwipe”

——————————————————————————————————————-

So what to learn from this? A few quick lessons and observations:

1) A mystery breeds intrigue

Being the mystery company…of the first TechStars…in tech hotbed and media mecca New York City…is a heck of a way to start things off with a bang.  TechStars tries to help companies make more noise and this is huge for OnSwipe.  On top of the buzz the other companies get, OnSwipe gets a huge extra magnification as people were looking to see what that 11th company was up to.

Lesson: If you can create some intrigue…definitely do! People love a good mystery.

2) Announce it and be AS LOUD AS POSSIBLE!

So we’ve got the source for Startup Tech News aka- Tech Crunch, writing about your funding announcement, a brilliant manifesto on the company blog by a truly gifted writer and the Angel investor that was the first to commit all writing about it at the same time.  Now that’s how you burn up Twitter and the social webs!

Lesson: The more ways you can get your message out, the wider the reach and the greater the buzz you can create.  Buzz = ongoing press attention, easier recruiting of employees and plenty of opportunity for serendipity.

3) The First Commit Came from BOSTON and was a new Angel

I’ve heard more than I care to about what it’s like to try to raise angel money in Boston and so it’s thrilling to hear that the first commitment for investing in OnSwipe was a Boston Angel (see Wayne Chang’s blog post).

Lesson: Boston.is.not.dead. There’s good people and if you show you have the right idea, the right team and the right skills, you can get funded around here.

4) Jason is the PERFECT choice to execute on this idea

Jason is a truly gifted writer/blogger both on his own blog: http://jasonlbaptiste.com/ as well as for the past few months Dharmesh Shah’s widely read OnStartups Blog: http://onstartups.com/ So when you take someone who is reaching tons of people because of his gift of writing…and happens to be giving tons of great advice on being an entrepreneur, that’s a perfect fit for someone that wants to lead a company that wants to change the way content is consumed.

Lesson: If you’re pursuing an idea, think about why you are the PERFECT choice for the idea. Then make sure the investors you pitch know why.

5) Jason has the BIG VISION investors love

So besides solid domain expertise, a solid personal brand to leverage and an initial product that is apparently already impressing investors, you have a guy ready to take on a big vision of how to transform an industry.  In his post on OnSwipe, he says it all:

“…50 billion dollars of traditional media spend needs to shift online.  Our belief is that it’s in a holding pattern and can’t. There’s a disconnect between award winning beautiful ads found in print and tasteless spam ads that litter the web. We think touch enabled devices can let this change by providing advertising people actually enjoy with the best of the web layered on- mobile, local, social, and more.”

Lesson: Think BIG, but be grounded in understanding the macro trends and opportunities.  Share that vision with the world and execute.

——————————————————————————————————————-

So to me, this is a home run all around at this stage. Yes, they still have to execute, but they’ve got an exciting and awesome set of pieces in motion.

This is the first of what I’m sure will be many more major steps in the future of OnSwipe.  I wish Jason and the rest of his team all the best and look forward to using it on my iPad soon.

Book Review: Mastering the VC Game by Jeff Bussgang

As a young entrepreneur, it’s not easy to understand how venture capital really works. There are tons of horror stories that spread through the community like urban legends and phrases like “Term sheets” and “Down Rounds” can sound foreign.  Amidst all of these questions is an aura of uncertainty about how the whole system really works. Fortunately, there’s Jeff Bussgang’s book, Mastering the VC Game to help.

This book should be a must read for any young entrepreneur who thinks they may ever want funding. It’s that good. Here’s a few reasons I love the book:

It Answers My Questions:

For a long time, I’ve had a million different questions about how it all works from start to finish and why certain aspects of the investment process are they way they are.  In Mastering the VC Game, Jeff breaks it all down in simple terms that have immeasurably raised my understanding how it all works. He’s also fair to both entrepreneurs and VCs alike, in explaining on how varying motivations can lead to all those conflicts and horror stores we hear about.

Thanks to this book, I now have a basic framework and understanding to build off of should I ever pursue funding.  I thought I was going to have to go to a ton of events about funding to understand venture financing, but this book is much clearer than putting together piecemeal information from events.

Read the other reasons at Greenhorn Connect…

Book Review: Gary V’s Crush It

If entrepreneurship was a team and we had a big game coming up, I have no doubt that Gary V would lead the pep rally and carry the spirit stick.  If you need a book to jump start your passion for entrepreneurship, to remind you why you do what you do and give you some tips to better succeed at what you are passionately pursuing, then Crush It is is the book for you.

When I first started reading this book, I wasn’t sure I was going to buy into it. It felt like sort of fluff.  But Gary V’s enthusiasm is contagious. Before long I was really feeling charged up about his beliefs in pursuing your passions and thinking about how I’m already doing it and how I can do more.

Compared to some more academic entrepreneurial books, this is a quick, easy read (142 pages), but it still is filled with great ideas and concepts.  After feeling like Chris Brogan’s Trust Agents was a bit verbose, I was very happy to breeze through this book. Gary hit on a lot of great points and covered a reasonable number of topics, but never dwelled on any idea too long.

If you’re looking for a quick read to get you pumped up to pursue your life’s passion AND have a method for actually making money on that passion, this is well worth the time to read this book.  If you don’t like overly casual/conversational books, you may want to steer clear of this one.  If I had to boil the book down to one principle, I’d say that it’s “Discover your life’s passion and create interesting content about that in the form you want, then be patient and get paid.”

Next Book: Steve Blank’s 4 Steps to the Epiphany

On Deck: Open to recommendations…

In the hole: Open to recommendations…

Book Review: Chris Brogan’s Trust Agents

As I mentioned in my New Year’s Resolutions post, one of my goals was to read a book per week this year. The first book I chose was Chris Brogan and Julien Smith”s Trust Agents.  This 260 page social media gem took me a bit longer than a week (9 days in fact), but was well worth it.  Here’s a quick review:

This book provides a step by step philosophy and guide for how to become a key member of the online and offline world.  This is really a “how-to” on being a great person who is valued, trusted and genuinely liked by others.  If you’ve ever followed any of Chris Brogan’s work such as his blog, or the awesome “overnight success” video series you know that basically this is a detailed book on how he did it.

The really strange and amazing thing about reading this book for me was the realization that I owe a lot of Greenhorn Connect’s success to the principles Chris and Julien go over.  At times, this made me inpatient reading it as I wanted to get on to topics I didn’t already know and practice, but at the same time, it was reassuring and helpful to understand those principles better.  Often, you can see success and attribute it to the wrong things.  This book helped me realize some of the things I’m doing that are helping lead to success. It also surprised me how often things that were happening in my life lined up with things I was reading in the book.  That includes the inspiration for my post earlier this week on business card etiquette.

I’d like to give this book some deeper analysis, but really all I can say is that YOU should read this book. It’s about social media and so much more. Not only will it teach you key tools and tips for taking proper action in social media, but it also shows you how to become a genuinely likeable person who succeeds.  If I had to boil the book down to one principle, I’d say that it’s “Pay it Forward both online and offline and it will all work out for you.”

Next Book: Gary V’s Crush It.

On Deck: Steve Blank’s 4 Steps to the Epiphany

In the hole: Open to recommendations…

Business Card Etiquette

As promised in my last post on my New Year’s resolutions, here’s a quick post. This time about Business Cards. I was inspired by both reading Chris Brogan’s Trust Agents on the subway trip home from #OpenCoffeeBos as well as by my own experiences networking in the Boston community.

Business Card Etiquette

1) Start at the End

There’s nothing more annoying than when people lead with their business card.  As Chris Brogan mentions in his book…you need to build a connection before your card has value.  Giving out a business card should be a reaction to the conversation you have with another person. It should be a means (way to contact you) to an end (follow up email/meeting/deal).  Men, you wouldn’t ask a girl for her phone number the moment you met her, would you? And ladies, you’d never give that guy your number, would you?

2) Leave some White Space

We all want to make a good impression and have the right information on our cards, but let’s not complicate things.  Leave some white space,  so I can take notes on the card.  I don’t have a great memory and often meet many people at an event. It’s really helpful to write a few words on the back of your card so I know why I want to follow up with you or simply where we met when I add you to my stack of cards from previous events. This also means making sure your card is a light background at least on the back…if it’s glossy or a dark color, my efforts to write notes are futile.

3) Keep it Simple

The value you create should not be in how cool or catchy your business card is.  If you network properly, people are going to go out of their way to pull out your card and add you to their contacts and/or follow up with you.  Focus on building those relationships and you’re more likely to get noticed.  When I go through my pile of business cards, it’s because I’m looking for someone in particular, not to randomly choose a card from the stack.

These are a few things that stood out to me recently. What are your tips for business card etiquette?