What Product Managers Can Learn From Hackathons

I love this recipe. It’s called Hackathon Stew.

Step 1: Identify a problem that needs to be solved and apply design constraints.

Step 2: Cram hundreds of developers and designers into a pressure cooker of a room.

Step 3: Turn on pressure cooker for anywhere from 4 hours to a few days.

Step 4: Examine the final product and decide if it is edible.

When done well, it’s amazing, like nothing you’ve had before. Problem is that the final product often comes out half-baked, which means most of it gets tossed out. That’s a lot of waste.Hackathons may not be the most productive way to create new products and features, but Product Managers can still learn many best practices from them, including the benefits of good problem definition, the importance of deadlines, and the strength of a small dedicated team. Couple those best practices with a product manager’s market savvy and that previously  inedible Hackathon Stew can come out consistently appealing.

What is a Hackathon?

A hackathon is a “contest to pitch, program and present a functioning… application” in a short timeframe, usually in the range of a few hours to a few days. There are hundreds of hackathons each year and they typically serve a few purposes:

1. Create an innovative new business, product or feature

2. Allow rock-star (and wanna-be rock-star) developers and designers to prove their mettle against other talented tech folk

3. Provide a platform through which aspiring (and experienced) developers and designers can learn more about their craft by doing it and learning from their peers.

The truth is that while creating something new is often the main stated goal, most participants find the learning and doing – the process of creating – to be the real draw.Hackathons have proven to be a versatile construct, a type of contest that can be structured to address any number of problems in an array of industries. It’s no secret that hackathons are embedded in the Facebook and Google mythologies; there are also hackathons run by companies like  LandRover, Major League Hacking, and Purple Monkey Game Jam...to name a few.

What Can a Product Manager Learn from a Hackathon?

Despite how many different domains have appropriated the hackathon approach to innovation, the basic format remains the same. There’s lessons to be learned in them-thar hills!

Tightly Defined Project (and Product) Scope

Hackathons begin with a discrete goal and concise problem definition (or requirements, if you will). Then they lay out the constraints each team will need to work through. One of those constraints is the timeframe in which each team needs to complete their work - the deadline. Each team is faced with a level playing field at the start in that they are working from the same requirements and under the same constraints. And they are usually starting their project from scratch. Each team has the same starting line. An example might be: all teams have 24 hours to develop a tool which will improve Boston’s streets (and the output might be a mobile app that detects potholes).Participants do not spend time debating little, menial requirements, they focus on finding the best, actionable solutions given the time constraints and their skills. They may ask questions at the beginning to better understand the competition’s requirements along with the tools and assets at their disposal, but they are most likely not wasting valuable time debating  specific feature specs and requirements. Cases in point: The Dread Pirate Roberts took inventory of his assets when figuring out how to storm the castle (see: Wheelbarrow). MacGyver did not lament his circumstances, he made the best use of what was available, usually under extreme deadlines. (More on deadlines, below.)

The Lesson for PMs: Well-Defined Product Requirements Matter

Well-articulated requirements define the problem and constraints without hemming in the solution. It’s your responsibility as a product manager, customer-expert and market-expert to craft great requirements. Once the “What” or “Why” are defined, give the tech folks room to figure out “How.” Get out of the way as much as possible.

Tight Deadlines

Douglas Adams, the patron saint of procrastinators everywhere, said it best: “I love deadlines. I love the whooshing noise they make as they go by.” The reality is that deadlines are essential, and force us to get stuff done, and the tighter the deadline, the closer it is, the more real and actionable it becomes. It’s hard to take a deadline that is many months (or even years) in the future seriously too much can happen in the intervening time. A nice side effect of the characteristically tight deadlines we see at hackathons: less planning, more doing.As Parkinson's law states, “work expands so as to fill the time available for its completion.” In reality, some deadlines are more immutable than others: imagine being on a deadline to launch a probe to Pluto knowing that if you’re late, your next window to attempt the project will be in two centuries.Hackathons amp up the time pressure to an extreme. This forces teams to make all sorts of tradeoffs along the way, mostly because they know that the deadline is real and there is no option for an extension or a delay.

The Lesson for PMs: Deadlines are Critical to Getting Stuff Done.

(And they need to be set within the foreseeable future). Think in small increments vs. massive plans. Deadlines should not be arbitrary, nor should they be flexible and infinitely negotiable. It’s not a suggestion – “Would you please please please have your work done by next Friday at noonish?” A deadline is a commitment. Treat it that way.

Small, Autonomous Teams

“Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has.” - Margaret Mead

Margaret Mead was on to something. Every member of a hackathon team has a direct role in the team’s success or failure, and each individual brings specific skills to the endeavor. No deadwood. No coattail riders. No hangers on. Everyone has a role, and is accountable to their teammates.Just as important to note as the team’s makeup is the fact that each member is often completely autonomous; they have all the authority they need to self-manage and get their work done. Imagine if teams had to get signoff from some committee during a hackathon? P’shaw.A small side note: since the team needs to make all of their own decisions, they also need to communicate effectively and collaboratively prioritize and ultimately decide what’s important. They’ll need to work together to decide which approach to take, which features to build, how it will all work together. And given the time constraints, there is no time for endless, pedantic debates. Make a decision and move on. “Code wins.”

The Lesson for PMs: Fewer People, More Skills & More Trust

When possible, keep your team small, and rather than focusing on headcount focus on ensuring the right skills are represented within your team’s members. Trust your team to make whatever decisions need to be made, however they want to make them. Provide guidelines if needed while allowing them to be self-sufficient problem-solvers. (You hired them because you believed they could solve problems; give them the space to do their jobs will show them you believe in their abilities.)

Focused Deliverables

Given the time, skills and tight requirements, teams will (or, actually, must) produce a focused deliverable. Scope creep? Extra bells and whistles? Sure, but only if time permits. But first, address the core requirements. Do (winning) hackathon teams spend endless hours refining the drop-shadow on a button? Um, not likely.

The Lesson for PMs: Stay Focused

Solve the biggest problem first, then worry about features and shiny objects.

Rapid Prototyping (aka Actually DOING Something with that Idea)

Ideas are cheap. Product ideas, feature ideas, business ideas. Cheap. Cheap. Cheap. They become much more valuable once they are turned into something. Given the extreme constraints of a hackathon, the focus tends to be on creating a viable prototype which accurately proves out the idea or concept. It can be rough, held together with plywood and duct tape, but it needs to WORK.“Most of the time, development is focused on stability and scalability, but they can also design for adaptability. So start any new product with a design for adaptability, with the understanding that most of this code will be thrown away. This allows you to decide what to do fast, and then focus on designing how to do it at scale,” says Tom Chi (by way of Martin Eriksson),

The Lesson for PMs: Embrace the MVP

Turn ideas into prototypes to quickly vet them out, but don’t try to make something perfect until you know how it will work and, most importantly, how your customers might want to use it. Take time to validate your ideas.

One Problem, Many Possible Solutions

When there’s many people working to solve the same problem you’ll ultimately end up exploring a more diverse set of possible solutions than a single person or team would. Very often, we as individuals are quick to converge on a single idea and see if it bears out. By allowing teams to rapidly prototype many ideas, hackathon sponsors get a better sense of the pros and cons of several approaches, and can compare them side by side (not just in theory).

The Lesson for PMs: Your Solution is Not Necessarily the “Right” Solution

Explore different approaches before deciding that one is the leading candidate. Solving the “right” problem means nothing if you don’t solve it the “right way” so solicit different points of view and be open to trying more than one solution.

Transparency (e.g. Prototyping in Public) & Collab-atition

Like all of my favorite reality-TV competitions (Top Chef, Iron Chef, Project Runway, in case you were wondering), everyone does their work in plain view of the competition during a hackathon. This creates a huge opportunity for teams learn from others, see if their approach is the same as someone else’s, modify designs on the fly, and in some cases, even join forces and collaborate with other teams.

The Lesson for PMs: Don’t Be Afraid of Transparency

Don’t be afraid to share what you are doing early and often, solicit feedback, and learn from what others in your field are doing. “Stealth mode” should be a four-letter word.

Quick Feedback Loops & Small Reveals

One of the biggest advantages of a hackathon is its short duration with the promise of real feedback at the end – be it in the form of “You Won” or “Here’s why you lost”. Imagine if you were able to quickly create and build out a working concept and get real, tangible feedback from people that matter. Not political bullshit feedback, but actionable, tangible, constructive feedback. That’s win #1.Win #2 is that you can only build so much in a short time, so there is no “Big Reveal” at the end of a project. You’ll have made an incremental step, and if you are way off, you’ll still have time to course correct.

The Lesson for PMs: Feedback is Key

Collect feedback and iterate often, when possible aim for the “small reveal” instead of the big reveal. Seek out and listen to feedback, and adjust your approach accordingly. (Sounds kind of like agile development, eh?)

The Learning Culture

Imagine if it was not only OK but expected to admit you did not know everything. Remove that shame or fear, and imagine just what you could learn. That’s the culture at many hackathons: it’s as much about learning new skills as it is about completing the project. Actually, in many cases it is even more about personal growth than it is about winning. With that attitude, it is possible to approach others and learn from them. It fosters a culture where people learn how best to work with each other.Winning is a nice side-effect, but for most participants, they will get personal enrichment from learning new skills and approaches. When goals no longer revolve around “winning”  the doors to collaboration are opened. Back to Tom Chi who emphasizes the power of a “culture of learning”: “Most product organisations struggle not because of a lack of technique and tools but because they suffer from the culture of right and wrong, where success is rewarded and failure is punished. This is intrinsically diminishing, as you never focus on learning what made anything successful or unsuccessful.”

The Lesson for PMs: Always be Learning

Retrospectives are a great tool to glean lessons learned from even the most disastrous experiences.

Building Your Personal Brand

Ultimately, one of the biggest advantages of hackathons, on a personal level, is that they are an opportunity for folks to prove their worth. Resumes matter little in this context; a hackathon allows participants to demonstrate what they are capable of doing. Hackathons are both great platforms and environments for capable doers – don’t tell me what you can do, show me. Loud thinkers, bloviate elsewhere, we’re looking for doers.

The Lesson for PMs: Measure Worth by Experiences

Resumes are a useful shorthand, but what really matters is what you have done and can do. The best Product Managers are doers, marrying vision with execution. Prove yourself everyday by doing.

Failure IS An Option

The philosophy that underpins all hackathons is that failure IS an option. It’s acceptable to try something big or ambitious or beyond your skills and fail. The consequences of failure at a hackathon are trivial, and in the end if you do fail you likely learned something in the process; you’ve put yourself out there, and by applying and doing, you’ve learned more about yourself, your team, and your capabilities. There is no shame in trying and failing. There is only shame in not trying.Each year, Facebook engineer Paul Tarjan says he travels to 10 universities, where around 200 students compete in Facebook-sponsored hackathons,  “We once tried to do a collaboration between engineers and MBAs,” Tarjan says. “It was pretty awful. They would build something that’s exactly like a market leader and put a spin on it. Like, a Groupon clone. I much prefer hackathons that just try to throw it at the wall and see what sticks rather than focusing on a cold and calculated ‘What will make money?'”

The Lesson for PMs: Be Okay with Failure

It’s difficult to succeed to the extreme and be novel unless you are willing to fail. There’s safety in the clone wars, but not a lot of innovation.

“And The Winner Is…”

In the real world, there are winners and there are losers. Everyone does not get a medal or ribbon just for showing up. (Even little kids understand just how contrived the “everyone wins” attitude it.) It’s a competition, and not every end product is worthy. Hackathons are a great way for you to learn and also to see how you measure up to others.

The Lesson for PMs: Not Every Idea is a Winner

Strive to separate the winners from the losers. Fight mediocrity and create a winner.

The TL;DR

Product Managers can learn a lot of “product management best practices” and good habits from Hackathons; from the setup, execution, and delivery of a product, to creating an environment in which people can thrive, to dealing with deadlines:[yes_list]

• When setting up a project or planning a release, craft a well-defined scope, set and adhere to tight deadlines, and give small teams authority and autonomy.
• From an execution standpoint, spend time up front creating rapid prototypes to help the team converge on a solid approach before over investing in a production-ready system.
• When delivering a product, focus on the “small reveal” as opposed to the more dramatic “big reveal”.
• And finally, looking at the culture and personal aspects, hackathons emphasize a culture of learning and allow participants to build their personal brand.
• Underlying all of the activity around a hackathon is that failure is an option and more importantly the best executed idea wins.

[/yes_list]