Startup Adventures at Stanford

I worked on two very different startups, with two very different teams, during my MBA at Stanford.

One team was focused on building a language learning platform for first-generation immigrants, in order to help them build their confidence and speak English more frequently. We were based at Stanford’s d. school, focused deeply on need-finding using design thinking principles, and had two product designers and a computer science major on our team.

The other team’s goal was to build a non-invasive tool to help glaucoma patients measure their eye pressure, in order to proactively manage their condition, and prevent blindness. We were based at Stanford’s Engineering School, had two electrical engineers, a patent-holder and professor, and an economics major on the team.

I am very grateful for the diversity of experience and learning, but am also struck by how transferable the lessons from these very different experiences are. These are my key takeaways:

Start somewhere: your product will never be ready

The starting point for both teams was different: on the first team, we had a blank sheet of paper, and began by defining user need. On the second team, we had a patented technology that we were trying to commercialise. Our level of fear, uncertainty and excitement differed based on our stage of development. However, surprisingly, this didn’t make as much difference as I thought it would to our day-to-day activities- except when it came to raising money.

You’re always going to have to continuously iterate and improve your product, no matter the stage you’re at: the challenge is ensuring you have enough time and resource to be able to fail fast, and developing a clear set of priorities of what you want to change and build over time, based on user feedback. Defining our minimum viable product was often one of the most challenging exercises we undertook at every stage.

Empathise with and delight your customers

Both teams used design thinking processes to understand consumer need, prototype and iterate, given that we were building consumer-focused software in both cases, and were aiming to help our users create new habits, albeit in very different contexts.

We were often surprised at how wrong our initial assumptions about our target consumers were, when we did in-depth consumer interviews to gain insight into their pain-points.

You have to be able to develop empathy with your users, and put yourself in their shoes when you’re trying to develop an understanding of their needs, or get feedback on your product. However, you also have to retain the ability to deviate from what they tell you they want- and surprise them- in the hope of delighting them- because they don’t always know what they want or need until they see it.

Great processes are easier to replicate than cultures

Both the teams I worked on very extremely high functioning. The diversity of skill-sets and perspectives, based on education, professional experience and nationality, greatly enhanced our productivity. However, the same factors also sometimes made seemingly straightforward tasks, such as scheduling interviews and gathering customer feedback, more difficult. We worked through this by agreeing upon team norms and values (such as being transparent, asking for and giving regular feedback, asking for help when needed) upfront. The importance of regularly discussing, repeating and reinforcing these principles will stick with me.

I also learned the importance of ensuring that the team had a shared vocabulary, was unafraid to ask ‘basic’ questions, and challenge the direction we were heading in: most of our mistakes were a direct result of miscommunication or ego.

People management matters as much as product management

At the start, I was insecure about my inability to code, given the strong engineering talent on the second team- but I quickly realised how much value I could add, through ensuring the team was working on a shared vision, that our work-streams were being actively managed and coordinated, and that we stayed aligned as a team across important and/or difficult decisions.

I learned that being able to read, motivate and manage people matters as much, if not at times more, than the product you’re building.

You have to be able to influence stakeholders at every stage: you’re constantly selling your idea to existing and new customers, investors, potential hires and your team.

Mission matters

Both ventures had an ambitious mission- this also ended up being an importance force in attracting great people, and allowing us to stay aligned. If you begin by building a stellar team, who’s bought into the company’s mission, you can work together to execute on all the basic steps a startup needs to follow- such as choosing a target market, building and testing prototypes, and experimenting with business models. However, if you’re unable to motivate and align your team, it doesn’t matter how great your idea or product is.

Feedback is a gift: you’re a work in progress

If you can’t manage yourself, you can’t manage others. Being able to see yourself from a distance, continuously learn, hire for or delegate your weaknesses, and staying unemotional about your work matters.

Your product will always be a work in progress: so will you.

We set up quarterly team feedback sessions for both teams: and I was always impressed at how much I learned about myself and others from these. These sessions also greatly helped build relationships within the team. They both helped clear the air when necessary, and build trust.

Startup Adventures at Stanford was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.