An engineering internship program typically runs 6 to 12 weeks, often as a group exercise. Interns join scrums, 2-5 interns (generally 3), where there was a known deliverable on a topic of interest. They would experience the corporate version of their classes: understanding problems, sprinting to solutions, and presenting to the team on progress.

Problems to tackle will usually be areas needing investigation but not yet critical path for the business. Guidance comes from a team lead or senior individual contributor, who advises and runs a daily intern standup in addition to their team standup.

I’ve seen that program a few times. I don’t really like it… the projects can be poorly considered and don’t go anywhere, and the interns don’t end up understanding why the projects would or wouldn’t work in the real world. So it’s a lot like hackathons, only stretched over a summer instead of a week.

I’ve probably seen half a dozen force-directed graphs of data sets that could never scale at a real customer, along with a bunch of pointless dashboard re-skins. Not to mention solutions that could technically work but are not feasible in the company’s licensing model or data system.

What the interns do learn is process and culture fit. That’s not terrible, but a lot of it can frankly be taught in school instead. It’s totally wrong for product management. So how should our internships go instead?

Maybe this is regional, but in the SF Bay Area tech companies are competing for interns. You can win excellent candidates by showing why they’ll do real work which will ship. Intern wants to get a job. “Got to prove culture fit at $HouseholdBrand” is one path to that. “I shipped a feature at $Elsewhere and here it is” is another one. “Proved culture fit at $Elsewhere” is not so good.

Set that as table stakes and you’ve got a good base. Next, focus on how to teach product management. There are different philosophies for that, which I’ll touch on in another post.