Build Teams at Texas Convergent
This past semester, Texas Convergent launched the Build Team program as an opportunity for students across the University of Texas at Austin to learn and test product development skills through a case-based curriculum. Each Build Team consists of 6–8 students from across the University. Our aim was to have a mix of tech, business, and design-oriented students working together as they would in an industry or startup setting. In our first semester running the program, we had over 130 applicants and over 10 teams formed, more than tripling the numbers we expected during our summer planning.
The case-based approach
We intended for the learning approach to be similar to that of a case competition or hackathon throughout the semester. These cases were designed with the help of alumni and external advisors to incorporate aspects of the product development lifecycle. For each case, we provided some background, an intentionally vague problem statement, and hints at possible solutions. We outlined a list of potential deliverables before the end of the semester, depending on the skill level and interests of the team:
- Front-end mockup inspired by findings from user experience research (potentially accompanied by its implementation in HTML and CSS)
- Back-end with the solution’s core features with mock data (if applicable)
- Presentation slides (similar to a pitch deck) along with a business plan — if it’s a B2B SaaS, develop a pricing model and projections
They were not expected to complete a fully-functional solution — instead we were aiming for a “proof-of-concept” for what they had come up with. What they came up with overall was pretty impressive! All of their slide decks contained some indication of existing pain points, a SWOT analysis, NABC outline, and many of the teams wrote actual working code!
Each Build Team worked on one of four cases throughout the semester. Note that we did not actually partner with the following companies — they were used as an education tool for developing proof-of-concepts to propose improvements to real companies.
Here they are:
Consumer Analytics — Know how Netflix recommends shows to you based on what other people like you have watched? That’s called collaborative filtering, and that’s what one of teams worked on using the Yelp data set. Using the history of restaurants you’ve been to, it could recommend other restaurants that people like you also enjoyed. Another team designed a creative way to consolidate “stamp card” reward eligibility for frequent patrons at restaurants, in an all-in-one stamp card app. One team focused on redesigning Yelp’s review process to prioritize ease of access and usability. Finally, there was a team focused on an algorithm to identify “trendsetters”, i.e., “early adopters” that review new restaurants with a sentiment that ends up being consistent with the average once more reviews pile in. They even took on the potential issue of “elite” Yelp reviewers being promoted to review newly-launched restaurants well by designing an anonymity feature!
Retail Technology — Wi-Fi beacons in department stores that help shoppers using an app to locate items, and assist salespeople by updating the store’s inventory in real-time! An app that randomizes outfits from JCPenney’s selection to fit your preferences using machine learning, and gives you discounts! A “flash sale” countdown feature added onto JCPenney’s site to take advantage of millennial impulse-buying, “awaken competitive spirit in people; the urgency and excitement clouds judgement” (verbatim from their slides). We were impressed by the creative ideas and research that came out of this group.
Social Media Monetization — Lots of companies have customer support accounts on Twitter (e.g., AppleSupport), which people tweet at and receive actual help in their replies. So, one team designed a customer support-oriented B2B product that centralizes customer support tweets for company employees to easily use and delegate response tasks. One team performed user experience research on a newspaper-like tab for Twitter. Another team developed a marketplace tab for users to buy and sell items, kind of like Facebook Marketplace. This team had a fully-functional backend written in Java, utilizing design patterns and everything!
Market Analytics — This case admittedly had the broadest scope, which led to some initial confusion, but the students ended up working on the ideas they were most passionate about. While the two teams assigned to this case ultimately settled on using data collected using the Twitter API, each team applied their data in very different ways. One created a Bitcoin price predictor based on real-time sentiment analysis of tweets, while the other used natural language processing techniques to gauge historical public opinion on Brexit against the British Pound.
Engineering an organization
Here’s a sneak peek at our internal processes.
Lead Recruitment — Each group of teams working on a case had four Build Team leads, so we found 16 leads, who are formally considered officers of Convergent. These were usually upperclassmen whom we interviewed at the beginning of the semester and selected for using a number of factors:
- internship experience/experience in other organizations
- intuition for business and product development (a typical conversation brought up with every candidate, regardless of major, could have been to pick apart Amazon’s profits and losses by product, or compare Snap and Instagram’s user growth, and so on)
- approachability and passion for helping others
Approachability is a crucial yet underrated trait, especially as it comes to picking leaders that students will be looking up to and asking for help.
Sprints and Case Group Meetings — Build teams working on the same case met with the leads weekly and operated in one-week sprints, pretty much in the “agile” tradition. They were encouraged to use Slack for communication and Kanban boards on Trello to make it feel like working at a startup. This is how a typical Case Group (4 leads, ~25 students) meeting might have been structured:
- 0:00–5:00: Let latecomers trickle in, highs and lows, small talk.
- 5:00–25:00: Industry topic discussion — leads educate themselves prior to the meeting and bring up important topics that may or may not be related to their case, such as “What is the ‘cloud’, exactly?” or “How do machines ‘learn’?” We have standards for how these discussions are guided, to encourage a Socratic teaching strategy.
- 25:00–40:00: Mix of a weekly standup or sprint retrospective (occasionally a presentation from each Build Team to the whole Case Group), and plan for next week.
- 40:00–60:00: Q&A, work on cases, individual Build Teams coordinate to work on the case outside of the Case Group meeting.
After each meeting, the leads were instructed to fill out a document that contained four points: Attendance (how many students showed up to your meeting?), Activity (what did y’all do?), Engagement (how engaged were your students?), and Assignment (what work did y’all assign to them?). The goal of specifically addressing these four points was to provide transparency to the officers and document each others’ strategies.
Officer Meetings — One meeting per week for the director and leads to meet and pool together ideas and feedback for next week. These are efficient and fun; we made sure that these were meetings that officers would be looking forward to, instead of dreading!
Reflections and conclusion
To be honest, we started out with some lack of standardized processes for certain systems (e.g., collecting attendance, marketing) and inaccurate assumptions based off our experience with a not-so-similar sample of orgs. That means our first semester had a lot of trial and error. We ended up with data in the form of feedback, rough estimates of student engagement, and used these points to quickly iterate on and make the Build Team experience better on a weekly basis.
We ended up running Convergent like one might run a startup, which was pretty fun. Our officers put on many hats — in selling the organization to others, devising retention strategies for our students, or explaining how a web server works. Indeed, that’s because a lot of our structures, values, and internal processes stem from our collective experience at firms like these:
We hope that the Build Team experience was beneficial for our members — both as something to demonstrate to potential employers as well as an opportunity for new friendships, maybe future business partnerships.
What’s next?
This spring, we look forward to delivering an even better Build Team experience using what we learned from our first semester!
First, we’re adding a few more questions to our interest form to gauge applicants’ existing skills and match them to leads who can best accommodate their growth. Next off, we’re switching the four cases we had last fall with four completely new cases, including one focused on applications of blockchain technology! Finally, because the number of teams working on each case is roughly the same number of leads on each case, we will make an effort to fully integrate one lead onto each team. This provides the chance for easier and welcoming collaboration between the leads and the students when it comes to implementation-specific issues.
A student from this semester approached one of our leads and said that it was with the help of their case that they landed their first internship offer. Another started their own company, which was recently accepted into UT’s highly-competitive Longhorn Startup Lab. That is what Convergent is enabling.
Be on the lookout for posts on this Medium, by students of the build teams!
