This past Saturday, I presented a workshop on Ideation at the Society of Women Engineers Tech Day at UC Berkeley.

This post will be discussing ideation, MDB's program for newbies to explore what problems they should solve. If you haven't already, I recommend reading a prior post I wrote on how we teach the software development portion.

Table of Contents

• Context for the Workshop
• Why Ideation?
• Modifying Ideation
• The Workshop

Context for the Workshop

SWE invited a variety of Berkeley clubs to come and present to middle schoolers that had been going through computer science training.

I was representing the mobile club, since I'm the VP of Education (workshops are kinda my thing).

Why Ideation?

The first thing that came to mind was to do a workshop on mobile development. The issue with that, however, is that making a mobile app is complex. Compare it with making it a website. It's possible to write some static HTML, putting some paragraph elements and divs with some basic styling to create a website. It wouldn't be super complex, but it's something possible to build in 50 minutes with little technical experience.

Mobile apps, however, are far more intricate. Native apps built with Swift or Kotlin would require months of training after learning general programming fundamentals. Even React Native, which is easier to build faster in and leverages to desktop and the web through React, would still be infeasible.

I ultimately thought about what we do in MDB. I've already written about what our purpose is here. As a one sentence summary: we want to teach people to make solutions to problems, using technology. The knowledge of how to make solutions using technology is discussed heavily in the prior linked post.

The other part is, in some ways, even more important: what do you build?

---

It's a well-known adage that ideas are nothing; execution is everything. But some app ideas, objectively, could use some refinement. As an example - think about how many note taking apps there are. Maybe I'm a bit biased due to location and that I see a lot of personal projects to the point they all blend together, but do we really need another note taking app? Sure, maybe there's some new feature, like supporting multiplayer editing using AI or something. But that's not a feature that's solves a problem. It's a feature that's cool.

With that in mind, MDB has ideation. The goal here is to get in the right mindset about how to solve problems. It sounds obvious - make sure there's a problem, then solve it.

To be frank, I myself don't know the complete answers on what makes an idea successful. The point of ideation is to remove the mindset of making something because you want to, then finding people that would use it in favor of finding what people would use and then building that.

Of course, we go into a lot more detail. One of my favorite concepts is the idea of market positioning. Most solutions are fixing problems that current solutions fail to address, due to a lack of features or issues with the fundamental orientation. Solutions vary, so understanding what makes them different and where users are concentrated gives insight into what part of the market to target. Traditionally, market positioning is used for analysis for current competitors, which we do as examples; we also think about what part of the market might be underserved, whether we want to target that part of the market, and how we can solve their problems (and why current solutions can't).

You'll notice that I'm using the word "we" a lot. This is intentional, not the royal we. I see ideation as being collaborative, with multiple perspectives contributing to a shared exploration of what ideas.

Modifying Ideation

For newbies in MDB, their first semester consists of doing the training program in which they learn React Native (or iOS or Android in past semesters when those tracks were offered) and doing ideation. Ideation starts midway through the semester, with 2 to 3 sessions. These sessions feature slide decks, but also require newbies to think of ideas and pitch them to their peers.

This ultimately culminates in a final ideation project, where newbies take ideas from ideation, the skills from the training program, and pitch their final solutions at an event MDB hosts called Techfair.

It would be impossible to do the same thing in one 50 minute workshop. Therefore, ideation would need to be cut, requiring me to think about a few things:

1. What is the takeaway from this workshop?
2. Is the takeaway approachable for all levels?
3. Is the takeaway useful for this audience?

Programming languages and paradigms change very quickly (probably exponentially, comparing changes in the past 5 years versus changes in 5 year blocks 10, 20, and 30 years ago). Further, these students were probably not going to start companies after the workshop. Classes that are similar to incubators do exist, where students are required to make a company and pitch it.

Rather, I wanted there to be exposure to the concepts within software in approachable ways. That way, if a student looks at their phone and sees YouTube is adding a new feature, they might take a moment to consider why the feature was added and what changes that leads to in light of the competitors (Vimeo, Twitch, streaming platforms like Netflix, etc.). Note that this doesn't require looking at 10-Ks, doing financial analysis, or coding of any sort; it's far more analytical. One might even describe this as product sense, though I don't think this is a product management workshop.

One major change to the slides compared to what was used in the ideation sessions was a focus on relatable examples. Companies like Benchling, Retool, and Superhuman are rapidly growing and are prominent examples we discuss in ideation. But for middle schoolers, these are hardly interesting, and the consumers may be hard to relate to (consider Benchling, which focuses primarily on R & D, or Retool which focuses on developers - both of which are hard to emulate). Instead, I chose examples like Google, Spotify and Tesla that might be more relatable.

The Workshop

The workshop itself went decently. There were a few key things I noticed:

• It was hard to keep the engagement going throughout. Ideation is a process where there's a lot of questions, but some of the questions were simply challenging to answer.
• Students weren't able to create anything. Some of the other workshops had students use devices - such as using Python's turtle module to draw.

With that in mind, there were some students that were taking close notes throughout. Given the constraints of what could be discussed, I'm overall fairly happy with how the workshop went.

The activity at the end was to have the students:

1. Think of an app they use
2. What problem does it solve?
3. What's the market positioning?
4. Is it resilient?
   1. If so, why? What makes the app so good?
   2. If not, what is it lacking? How would you fix it?

Many students (3 groups) ended up picking Discord as their app. It was striking to me, as only a few of my friends even back in high school used Discord, and most people here at Cal use Messenger and occassionally Slack. Discord's popularity is interesting, and bears perhaps future exploration given the impact of remote school in the past few years and potentially how that might be changing.

With regards to changes to MDB's ideation - there are some examples that I switched out, which will be added to the regular ideation slides. The activity will also probably be incorporated into the first session of ideation, since it's a good way to get newbies to think about what they want to build.

Made it this far? Like what you hear about MDB? Consider applying! We recruit undergraduate students at UC Berkeley in the fall and spring semesters, and our application will be found towards the beginning of the semester at mdb.dev.