For several years, the final deliverable in the Software Product Management (MTAT.03.325) course was a report. Student groups validated problems, created a business model canvas, conducted user research, defined and prioritised MVP features, developed a roadmap and risk management document, and designed wireframes using tools such as Figma or Miro.

Often, the results were genuinely strong. But at the end of the semester, the product itself still largely existed just on “paper”.

And Then GenAI Entered the Course

GenAI began to change how students worked on the project.

Writing the report became faster. Students could use GenAI to summarise findings or prepare parts of the report much more quickly. Sometimes this worked exactly as intended, but when students relied too heavily on GenAI, the result often became generic. The fact that final project deadlines usually fall during the semester’s busiest time – May – probably did not help either.

At the same time, building the product itself became much easier for both technical and non-technical people. Tools like Lovable, Replit, and Base44 made it possible to turn ideas into working web applications using natural-language prompts. Claude Code, Codex, and Cursor accelerated product development by leveraging coding agents.

That raised a fairly obvious question for the course: if students could spend less time producing the report, and much less time getting a product version off the ground, why should the final outcome still be mostly a description of the “product” rather than the “product” itself?

What Does “Build the Product” Actually Mean?

Of course, asking students to build the product does not mean asking them to launch a production-ready startup in one semester.

For the course, a product would start meaning something much simpler: an implemented version of the core value proposition that another person could actually open, interact with, and understand.

The goal of the course was still to give students a practical understanding of software product management: how to understand users and the market, define the MVP and prioritise its features, think about user experience, choose meaningful product metrics, manage risks, plan what comes next, and make trade-offs when time and resources are limited.

Building, therefore, became an additional part of the course project. 

The result could be an MVP (or a “minimum lovable product” – MLP) with several working user journeys, or a much smaller interactive prototype focused on one core flow. What mattered was that students had to make the transition from describing what a product should potentially do to making decisions about what they could actually build.

Eighteen Teams, Different Ways of Getting There

Around 60 students – 35 were from Software Engineering, more than 15 from Innovation and Technology Management, with the remaining students coming from other programmes.

Lovable was the primary tool. With access provided by the Institute of Computer Science, students could move from describing a product idea to building, refining and deploying a working web application without first having to set up the entire technical stack themselves. 

Students who preferred to work directly with code could use Claude Code, Codex, Cursor, GitHub Copilot and host the application themselves. In the end, 14 teams used Lovable and 4 chose the self-hosted route.

That split also reflected the course’s mixed background. For somebody without much development experience, being able to describe an interface or flow and immediately see it appear was a major reduction in the implementation barrier. One student described Lovable as “a great tool to build projects for someone who doesn’t know how to code,” although they personally preferred Claude Code or GitHub Copilot.

From the teaching side, having a common platform solved several very practical problems. We could manage student access centrally, organise projects by team, support collaboration in a shared workspace, and monitor usage to ensure the available credits/tokens were distributed fairly. 

From Solar Parks to Student Housing

The team projects covered a wide range of problems: a marketplace for solar park projects, safer housing for international students, and a simple client portal for freelancers to share project progress without constant status messages.

Other teams focused on problems closer to student life: discovering events in Tartu, keeping track of university deadlines, and finding English-first jobs for international students.

That variety was one of the favourite parts of the pilot. Instead of eighteen versions of the same assignment, we had eighteen different products to open and explore.

What Changed When Students Had to Build It

When something exists only in a report, it is relatively easy to write that the MVP will include authentication, recommendations, integrations, notifications, analytics and five different user roles.

Implementation introduces friction. Students had to decide which user journey came first. They had to remove features. They had to work out what “minimum” in MVP actually meant.

That thinking is quite clear in the projects. For example, the solar-marketplace team postponed automated valuation and deep integrations with grid and cadastral systems. Those are product-management decisions, not coding decisions. And that, for me, is one of the strongest arguments for keeping implementation in the course.

Building With GenAI Also Changed Teamwork

There were, unsurprisingly, some new workflow problems.

Lovable effectively gave a team one shared conversation per project. If several people tried to make changes at once, prompts could queue, and students sometimes found it difficult to follow what somebody else had asked the system to do.

But the response was interesting.

Teams often ended up discussing a change first, agreeing on what they wanted, and then having one person communicate it to the system.

In traditional development, collaboration can happen around different files, branches and pull requests. In this environment, some collaboration moved before the implementation step: deciding together what should be changed and how it should behave.

The Teaching Experience Changed Too

There was another consequence, much less profound but still worth mentioning: the projects became more fun to assess. Instead of reading eighteen lengthy documents describing hypothetical interfaces and future functionality, we could open the applications.

Click around.

Try a user journey.

See how the product works.

Compare the final outcome with the MVP description that the team had defined several weeks earlier. The written work did not disappear. Students still documented problem validation, user research, alternatives, MVP definition and other product decisions. But instead of another large final report, we used shorter checkpoints and let the implemented product become part of the evidence of their thinking.

My impression was that this made the project more manageable and shifted some effort away from writing about the product towards actually developing it.

It did not magically cure the “May deadline” effect. There was still plenty of activity close to the submission date.

Did Students Actually Build MVPs?

Not every final project was equally mature.

Some teams produced fairly complete MVPs with several working flows. Some had interactive prototypes. Others were closer to sophisticated landing pages.

For a first pilot, I do not think uniform technical sophistication was the right success criterion anyway. The more relevant question was how closely the implemented result reflected the MVP that the team had defined earlier. Among the 21 students who responded to our survey, 20 said their team had fully or mostly achieved the MVP goals they had set earlier in the course.

And at the end of the semester, students could take those products one step further and present them at the University of Tartu Institute of Computer Science Student Project Contest.

All in all, the pilot showed that GenAI can make building a natural part of learning product management – connecting product decisions with practice and giving students something they could actually build, test and show.