Don’t set goals — prototype them

During the Matter accelerator program, the goal all our entrepreneurs work toward is the same: Demo Day. The path to get there varies team to team, but the core is common: at the end of the 20 week sprint, they will present the culmination of their efforts on stage in SF and NYC before an audience of 200+ investors, media executives, mentors, and more.

But what happens after Demo Day? Goals change. Driving momentum looks different for everyone, and that’s natural. Some teams use Demo Day to kick off fundraising, some focus on business development and growth, and others decide to keep working on product. And much like parents probably feel when their children leave the nest, we have to let them set their own trajectory. But also like proud parents, that doesn’t mean we can’t support them.

The crazy thing is, life after Demo Day…is pretty much the same. Demo Day is not the end of a startup’s process, and it’s certainly not the end of prototyping. The skills and structure we teach our entrepreneurs is meant to be lifelong. Demo Day is the summation of their hard work, but it’s also the beginning of the next sprint.

Entrepreneurs have told us that it’s sometimes difficult to go from twenty weeks of intense structure to…well, on your own. Specifically that entrepreneurs a) found it difficult to stick to structure without a community doing it with them, and that b) they missed the collaboration with the other teams. So that’s why we, the Matter team, decided to try something new: alumni sprints.

Alumni Sprints

These sprints are 4–6 weeks long and available for all interested alumni teams. They set their own goals and drive them forward using a scaled back Matter structure. In theory, it makes sense. In practice, however, this initial alumni program was not designed to weather the inevitable downhill loops in the rollercoaster of entrepreneurship. Without the proper norms around seeking feedback and accountability with goal-setting, it became clear that bad news never surfaced. This is a very human thing, by the way. When things are going well, we share. When things suck, we hide.

We developed this implicit norm that feedback was not to be given around goals, and clapping and cheering (no matter how feeble) would be the only appropriate response to goal updates. Somehow, we made the grave mistake of making goal-setting immune to the prototyping process.

Goal-Setting: Constraints

Goal setting is not immune to the prototype-driven process. In fact, it’s one of the most important things to prototype on and get feedback on since it sets up all the work you’re eventually going to do.

And just like ideation, goal setting is really about setting the proper constraints. I took my inspiration from the S.M.A.R.T. goal system, but further simplified it.

Critical: In early stage companies, time is the most valuable resource, so it’s important that goals are geared towards critical aspects to the business.

Concrete: Can you explain this goal to someone outside your company? Can that person understand how you’ll be measuring your progress? Can you hold yourself accountable?

Challenging: Is this goal challenging and compelling enough? In early stage ventures, when a six-week sprint may be all there is left, there is no time to be setting goals that are not goliath.

[Time is another constraint, but was a given since the sprint duration is set for 6 weeks.]

Goal-Setting: Process

This is the process we used most recently to kick off the latest Matter Alumni Sprint:

1. Prepare: Come prepared with the one goal your team will focus on during this sprint. Keep in mind the constraints above: critical, concrete, challenging.
2. Present: Each team presents their goal for 2 minutes.
3. Evaluate: The other teams then evaluate the presenting team’s goal with a hand-raise as to whether the goal is critical / concrete / challenging.
4. Feedback: There’s open feedback time from the group to the presenting team. The key to this feedback session is to set norms that the goal is a prototype, and honest, constructive analysis and questions are to be sought out.
5. Iteration: Allow time (~10 min) for iteration of goals based on feedback.
6. Set: Each team must write and post their edited goals in a publicly viewable spot in their workspace for the duration of the sprint.

It seems obvious, but the framework we have now is a result of our own goal-setting. In the beginning, we were not being concrete enough about our desired outcomes from this alumni program either. In trying a few different things (read: failing forward), we now know that setting up the proper constraints is critical to ensuring quality goals from the teams. And given that it’s always a challenge to poke holes in someone else’s framework if they’re not asking for it, we provided that very important forum so that clapping would not be the only response.

I’m interested to hear about how you set goals — what has worked for you and what hasn’t? What constraints do you find useful?