A visible lesson from Hacks/Hackers Connect in S.F.

When I first signed up for the Hacks/Hackers Connect event in San Francisco last weekend, I wasn’t quite sure what to expect. Aside from the usual feelings about meeting new people at the intersection of journalism, change and technology, I was avoiding having tangible expectations. As an engineer-turned entrepreneur from Bangalore, I am quite familiar with the buzz and excitement of the startup sphere. My city has its fair share of sparks, summits, sagas, pivots, acquisitions, social action by tech folks, and what have you.

As a JSK fellow this year at Stanford though, the central distinction is that I am OFF my daily office whirlwind. I have some real time on my hands to focus on a hard problem that haunts city newsrooms worldwide. I’m finding a way to keep newsrooms and reporters in the loop on ongoing sagas in a city when they are not reporting on it.

That’s all I took to Hacks/Hackers Connect in S.F. Ahead of the event, organizers had asked participants to post their favorite problems on a whiteboard online. I posted two or three different versions of my JSK challenge, mostly out of curiosity to see how random people might react.

The opportunity

What I’d expected on Saturday was a few talks and breakout discussions. I had identified a few people to meet from the Hacks/Hackers mentor list. What surprised me was that right after Saturday’s session began, Connect producer Philip Smith pointed out that the people who posted ideas on the digital board were the ones who would champion the working sessions through the day. They would get their problems discussed and “solved” within the breakouts!

I sensed an opportunity but cringed, having not expected it up front.

It is one thing to post an idea on a website before you go to bed, in the hope it gets voted up so you feel like your idea is the pulse of a bunch of people — which mine was not. It got less than half a dozen votes. It is another thing to say you are going to announce it at the event and hope that sharp people will volunteer to come by your table and discuss it. It’s a free country. People could just say “boring” and walk!

But the good thing at Connect is that Hacks/Hackers co-founder & 2009 JSK Fellow Burt Herman, Smith and his fine team had thought of the natural flow that occurs in people’s minds. After that announcement, we did not start the championing right away.

I went to a design thinking session run by Ed Bice and Heather Bryant. Both good listeners. I am familiar with the d-school (Hasso Plattner Institute of Design) approach at Stanford and used it for my end-user interviews through October and December. But I wanted to see how product people in the real world started out doing design thinking.

We had four different problems to discuss in about an hour, and did not get too far down into any one of them. Still, the best part was we got to know a little about each other very quickly. Because most of us there are wanting problems solved in the journalism/content spaces, it was also exciting to see how quickly common threads emerged from our life experiences and journeys.

The spark

Following that was the session that sparked the practical side in me: Dan Olsen’s presentation on LeanCanvas, a tool for quickly defining your business model. Olsen, a management consultant, is the author of the Lean Product Playbook. I think this approach of using a simple white paper drawn into a table structure to express your hypothesis-turned into-proposition is deceiving, frankly. You fill up the sections to state your problem, solution and other details pertaining to users, business potential, etc. You do this in such a way that you can see it all together in one glance, on just a piece of paper or a small whiteboard.

That itself is a stress buster, if you will. And you can change or add to it as you talk to someone. If only business plan writing were as simple as this. Olsen said it’s better to write business plans after doing this. LeanCanvas forces a problem solver to focus on whether or not they have a real solution to a real problem, whether the solution has an unfair advantage, who the target segment of end-users is, etc., and sketch that quickly.

Olsen, to me, is a fast-and-furious version of a startup educator. Within half an hour he had raced through both the principles and a few examples of how the problem itself changes when you start taking the tacit, unstated details and assumptions out of your head and putting them onto the paper or board. Nowadays, it’s called “iteration.”

Olsen is good at what he does. He was able to show a real world iteration on canvas – before a product is built, hence saving developers money. He showed us, for example, how a startup to build a marketing report for consumers (like a credit score) changed to a solution to free people from junk mail and allow them to opt in to specific marketing mail. Most importantly, to me, he visually showed the difference between a good, minimum-viable-product and bad one. He sliced the pyramid vertically instead of horizontally – showing that all aspects of a startup need to be prototyped, not just functionality – and that was useful. It brings a goal to the early stages of the product development process.

I was intrigued. Those of us who have done business plans before would have instinctively realized that this process does bring clarity quickly, and without making you feel stupid. Encouraged by that, when the time came for people to identity themselves to lead team breakouts, I decided to toss my JSK problem into the ring.

A contact sport

My initial concerns about takers were misplaced. It went the other way pretty quickly. We had five people at my table and two mentors. Aside from me, there was a UX designer, a nonprofit policy analyst who was also a watchdogger, a reporter for an industry vertical, an engineer turned journalist from Stanford,. Exactly the profile that made sense to me! HH mentors helped bring solidity and insight to the discussions.

We went at it. Most people understood my challenge. Trying to map it onto the canvas was harder. What I learned was that the visual element of the solution needs to be clearer and has to be matched to users experiencing the problem.

“Design is a contact sport,” says Michael Bernstein, professor and crowdsourcing expert at Stanford’s hallowed Computer Science department. That line almost jumped off the screen for me when I read his material for a “design thinking for people with tech chops” class last fall. Interaction with a diverse and yet invested set of people forces thinking in tangible terms, especially for a solution that needs to go through an adoption curve.

And that is what happened at Hacks/Hackers Connect San Francisco. Even as the conversations threatened to get into a runaway loop, the policy analyst in my group would bring us back on track to ensure the canvas kept getting filled in. It was helpful that one team kept us moving along. After lunch, the teams rotated tables one after another until each team visited five tables in quick succession. It was a like a flock of intelligent, cackling geese quickly going from pond to pond. Each of the team leaders, who stayed at their tables, had to pitch their problem-solution on the canvas five times back-to-back and get feedback. I am thankful that all the feedback was in Post-its and I did not have to take notes.

By 4:30 p.m., I was out of fuel. I lost track of what I was saying and to whom I was speaking. But I noticed that people listened and were more interested in constructive responses and questions. And perhaps I speak for others here: I certainly met new people and made connections that felt real.

Calling out the problem space

What could have been better? One of the challenges with tech-ish meetings is that the problem space itself does not get discussed in depth. What types of problems do journalists, for instance, have in their minds? Which ones fit the entrepreneurial approach? Which ones do not? How do nonprofits use LeanCanvas?

For instance, I wish that Dan Olsen had offered some journalism related startups (like Sqoop, Checkdesk) as examples. That would have brought a contextual sense of realism to the participants, many of whom were experienced journalists, with some lens on technology. Many journalists – often the first to recognize communities that don’t have a voice or whose views are being sidelined – create their own niche website-journals that become watering holes for those communities. Many of these efforts are a “solution” to a “problem,” but they do not easily fit the LeanCanvas approach even if the founders want to pivot to something that might generate serious revenue.

I am a journalist and technologist rolled into one person. There is always a tension. As a journalist I am skeptical of the buzz and glow around anything, let alone tech-led innovation. History repeats itself too often to be ignored. Uber may be classic disruptive innovation from a problem-solution standpoint, but there is no brushing away questions on the future of labor and collective bargaining power that such solutions bring up. The journalist in me helps keep things real and focus on the people involved. As a technologist, I am always keen on applying the possibilities of tech as a force multiplier.

I came away from Connect with both sides satisfied. I have my work cut out for the next few months. I’ll lean in to canvas, if you will.