Editor’s Note: This post was originally published on Seattle 2.0, and imported to GeekWire as part of our acquisition of Seattle 2.0 and its archival content. For more background, see this post.
By Sasha Pasulka
When I attended Startup Day last year, I was trying to sell my company. I’d founded it four-and-a-half years prior, made an unfathomable number of mistakes along the way, was tremendously lucky that the thing still had value, and I couldn’t wait to cash it in and start with a clean slate. I spent most of the day hanging with friends outside the main conference room. Listening to the speakers was a lot like discovering your opponent’s playbook the morning after you’ve lost the match. I couldn’t change the way I’d made those choices, and it was frustrating to get such good advice after the fact.
This year, I came in from a different perspective – I’m at a brand spankin’ new startup. Hell, we haven’t even released a product yet! (More on that later.) Any and all decisions are still up for grabs. We feel like we have the makings of something great – now it boils down to the execution, to the choices we make in the coming weeks and months. This year, at Startup Day, I was a sponge. I filled half a notebook with notes. Every speaker helped me address a specific issue I’m facing today – when I still have time to do it right. I left thinking how anyone looking to found or take a leadership role at a startup can’t afford to miss this event.
Here are three ways I’ve already incorporated what I learned at Startup Day:
1) My team is launching our product with fewer features than we’d initially planned.
“What is the simplest thing that could possibly work?”
Scott Porad, CTO of the Cheezburger Network, had this printed, in giant letters, on 50% of his slides. He asked us to meditate on it. He said it again. He said it a few more times. It’s a simple question, but startups struggle to answer it.
Scott reminded us to launch with the simplest thing that could possibly work, even if doing so implies rework later. Test the model. Test a single variable. Find out if your product works before you build more of it.
It lit a fire in me. The following Monday, I walked into the office, loaded up our team’s release planning application, and slashed 75% of the remaining stories from the initial beta release. I replaced stories like “Write character bios” with “Remove character bios.” I replaced stories like “Implement avatar hair options” with “Remove avatar.” I replaced stories like “Improve leaderboard UX” with “Remove leaderboard.”
The team was shell-shocked, and a little concerned, but it wasn’t up for negotiation. Two weeks later, we’ve iterated tightly on the small set of features that define the core of our product – the thing that we think users will think is uniquely useful about us. And it’s looking even sleeker, and working reliably. We’re prepared to show it to beta users two weeks from now, rather than in two months. Team morale has improved, and the tasks ahead of us feel less daunting. We’re proud of the product we work on each day, more than ever before.
2) We are using the scientific method to understand user behavior.
It is critical to determine how and why users engage with your product the way they do. Marc Nager, CEO of Startup Weekend, suggested talking with at least 20 potential customers before you take the first step toward building a product. Jonathan Sposato from Google focused on the importance of finding the feature set that resonates with your users, not the feature set that your team thinks is the coolest. Marketing guru Sean Ellis advised startups to listen to how their customers articulate the benefit of their product, rather than assuming you understand the perceived benefit. Rand Fishkin from SEOMoz urged us to test our assumptions about the market as whole, because the feature requests we get from our core, happy, engaged users may not reflect the needs of everybody else. All stellar advice.
But faced with thousands of different tools to report on millions of different data points, how do you start sifting through data to get to these answers? Where do you even begin?
Scott Porad suggested formulating hypotheses, like this: “I think that if ___________ then _____________ because _____________________.”
I love this idea. It forces you to find simple ways to express complex questions.
I took it a step further, and I told my team we’re using the scientific method – the same one you used for your sixth-grade science fair project – to test user behavior and make product decisions. We are writing:
1) The Question: One sentence only. What are we trying to find out?
2) The Hypothesis: “I think that if ___________ then __________ because _________.”
3) The Experiment: This is a definition of how we’re going to test the hypothesis. Which data will we look at? How will we get that data? Will we need additional equipment or software? Will we need to talk directly to users? Which users? Are there multiple variables? If so, how will we ensure we’re testing them independently?
We will review these as a team. Are we asking the right question? Is the experiment designed to answer that question? Are there too many variables? Should this question be broken into smaller parts? Are the results of the experiment actionable? We’ll iterate on it until we have consensus.
Next, we’ll run the experiment as defined. We’ll analyze the results. We’ll draw a conclusion. We’ll decide on an action.
3) We are sending the devs to parties.
Megan Casey from Squidoo talked about things you can build before you can build your product. She emphasized that you can build a community, and you can build community support. You can become a part of whatever community you’re working within, and be a recognizable face and name around it.
I brought this back to the team: “You guys have to start going to events.”
While many of them have families and other demanding time commitments, they were game. Some of them had already dipped their toe into the startup community, and were willing to be more involved. “We just don’t know what the right events are,” they said.
Luckily, I do. (Although when I first arrived on the Seattle startup scene, I used more of a shotgun approach. The Django Seattle User Group didn’t entirely understand what I was doing there, but they were nice to me.) I began sending the whole team several recommendations a week for startup, tech, lean and product events they could attend to meet interesting people, learn something useful and, most of all, get the word out in the community that we are building a product and we would like support. So if you see Brad, Khan, Kailey or Brian at your next event, be sure to say hello. They want to be your friend!
