Be your product

Are you working on the next big thing? Here’s a few things you usually do :

  • find an idea,
  • convince yourself that it’s a good one,
  • build it,
  • measure the outcomes,
  • Do it all over again

Quite often, by the time the entrepreneur is done with the first product cycle, things start to get muddy, messy, and hard to analyze. The analytics are blurry, and the people you work with begin to wonder if they made the right decision joining the adventure.

It is sad to say, but many startups die off because a distance is created between the team and the reasons the project started for.

While conceiving your product, you invest a great deal of your time in programming, user-interviews, and business development. Structuring daily tasks in such a way will result in giving a fake illusion of productivity while driving you further from your mutual, team objectives.

But wait! There’s a better way tho’

At the crossroad of the GV Product Design Sprint and E.Ries’ Lean Startup lies the doubtful idea-to-execution. The beginning of things in a startup.

At Jam, we decided to embody our product and simply be it. With a team of 8, we pivoted from a campus-based social network (formerly ‘Blackbird’) to a personal assistant for each student.

Instead of spending months building an A.I. assistant, (using N.L.P. , text-to-speech features and whatnot), we acknowledged the pending difficulties, and emulated our product as “team-to-user”.

The problem we were (and still are) tackling is that student life is a hassle, and instead of focusing on learning and enjoying university, students spend a lot of time seeking internships, housing, events, etc. Since the problems are various, and the possibilities of friction points for each user infinite, we needed to go to the source of every single issue students had. We do not guess anymore, we only solve the problems that students tell us they have.

This extreme iteration amended our startup workflow to the point where we simply stopped everything we were doing : each member of the team was assigned a specific « field of request » (specialization as a personal assistant, e.g. « I can handle all the housing enquiries from now on » ), and the product became an e-mail based assistant. We even plugged our database into Trello and used it as a CRM to handle user requests. Various assistants and similar products decided to use Frontapp (the collaborative inbox, YC S14), which is a good idea in itself… only the Trello API provided us with a great level of “hackability” that we needed to make sense of our product.

We moved fast using Trello, Zapier, Kimono, Slack, and Google Apps and that was it: Boom! Product.

We have bootstraped trello to interact with our database

Since then, things have changed a tad. We have exchanged ~1.5M messages, and developed Jam Power, a state of the art in-house CRM tool when Trello proved unscalable.

Sometimes you can simply embody what is hard to conceive.

PS. If you are building an invisible app, reach out to me (anas at hellojam dot fr)