On Talking to Users #

During our VC meetings this past week, John Lilly brought up a generalized observation: a lot of folks seem to be guessing about what customers might want. This points to something broader: the important balance in 210 between rapidly prototyping and building something end users want.

As CS people, we all love going heads down and building as opposed to talking to people. Especially with the rise of AI tools, it’s easy to get lost in prototyping forever without talking to a soul. After all, it should be all about opinion-based design, right?

While trusting your gut and intuition is critical, at the end of the day, we’re hoping you guys end up building something that serves a larger group of people. Thus, as you all build, it’s equally as important to talk to users.

Defining your ideal customer #

First, it’s important to define who the customer/user of your product is. For liaison-based projects, this is often given to you by the organization itself. For the startup teams, you’ll have to work to best define the ideal customer profile (i.e., your ICP). There’s a lot of great guides out there on how to do this: Unusual has a great article in their field guide.

How to talk to users #

Based on your project, there are several ways to get feedback from users. For consumer-oriented applications, there are a couple tried and true approaches, such as running surveys of recruiting folks and interviewing them face-to-face. But in the age of rapid prototyping, it’s also easier than ever to quickly launch, share your demo on social media, and try and go viral. Trying to build something for college students? Great: build fast and get a video out on Fizz, the CS mailing list, Twitter, you name it.

For folks building enterprise applications, you can oftentimes be a bit more regimented. In particular: you’ll want to reach out to folks within your ideal customer profile and test for a sense of desperation for what you’re building. Viral demos can still be effective, but for SaaS, the typical playbook is to run cold outreach, ask the right questions to understand pains, and then eventually convert them to design partners. Unusual Academy will go over more of this in detail, but their open-source guide also contains some helpful information. As for an ideal number, there isn’t a required number of conversations for 210; at the beginning stages, though, you will want to have as many conversations to build the conviction to keep going. There are also lots of helpful tools to faciliate this outbound, such as Apollo.

Conclusion #

All in all, rapid prototyping does not mean only using your convictions and not talking to users. You have to do both, and the age of AI means the feedback loops can be even tighter. In fact, you should never stop talking to your users, whether it be for feedback, selling, and more.

By week 7, you’ll be presenting some of your prototypes for us… compared to previous years, you guys definitely have the ability to both ship something quick. Now, it’s time to use that saved time to test these hypotheses even quicker.

Good luck! As always, the teaching team will be here! 😃