Recently, I led the product development of a new software project. Our team consisted of 11 people with a mix of business and technical backgrounds (a 3:8ratio). In this article, I want to share my experience stepping into the Product Owner role and outline the management strategies that led our product to success.
The product in question is the one below:
Redefining the Product Owner Role #
My role was Product Owner (PO), though it was far from a traditional, purely administrative PO position. To ensure a smooth development process, it isn’t enough to just have a cooperative team of developers; you must hand them a clear, well-defined vision.
We followed a Scrum methodology, breaking down the project into logical steps to build from the foundational infrastructure up to the “nice-to-have” features through distinct value stories. We defined our tasks as User Stories, but we avoided ambiguity. A vague “As a user, I want X” can quickly spiral into a massive, overly complex task. To counter this, we also wrote stories from a developer’s perspective—aiming to create reusable features for multi-task integration.
This is a major challenge for a PO. It requires a clear vision of the sequence of events and the technical capability to break large features into smaller, interconnected slices. Having a strong technical background was crucial to anticipate these scenarios.
Managing a Team in an Academic Environment #
Coordinating a team of 8 developers is no small feat. It becomes even more complex when the team consists of Master’s students with limited large-scale corporate experience. Unlike a traditional company setting where there is top-down pressure from a team leader, a university scenario is much more relaxed. The consequences are lower, and peer relationships are more casual.
To tackle this, we employed a micro-team strategy. We split the developers into smaller groups of two or three. When I assigned a task, it went to a specific group. How they coordinated internally was up to them; the only requirement was that the task was completed on time. This approach worked incredibly well. It also solved the logistical nightmare of getting all 11 people into a single meeting for feedback or task clarification. Instead, I only needed to sync with one representative from each micro-team to keep the whole process moving forward.
Stepping Up: Design and Decision Making #
As the PO, I felt highly motivated to flesh out the entire business requirements. High-level planning usually produces broad concepts, but when I started breaking those down into User Stories, I noticed many missing or conflicting details.
In these moments, a PO needs the autonomy to make decisions without constantly asking for permission. While I wasn’t the CEO, I felt the responsibility to make the final call when no one else would. This requires a deep, holistic understanding of both the business and the technology.
Furthermore, communicating requirements purely through text is never enough. As the saying goes, a picture is worth a thousand words. Our team didn’t have a dedicated designer, so I took on the UI/UX role myself. While this added weight to my responsibilities, it taught me a valuable lesson: the more detailed and realistic the mockups, the easier it is for developers to build the product. You cannot just tell developers to “do whatever you want”—it’s unrealistic and leads to poor results. Designing these interfaces also forced me to think about missing details, like exactly what data should populate a screen, which are rarely discussed during high-level planning.
Figure 1: Taking on the UI/UX role: high-fidelity mockups in Figma leave zero room for ambiguity.
The Anatomy of a Perfect User Story #
Another critical skill I honed was task prioritization. You must constantly evaluate what is essential for the initial build and what can wait. We used a value matrix (Critical, High, Medium, Low), focusing heavily on the critical tasks during the early sprints.
For the developers, we also estimated the effort (technical complexity, time, or learning curve) using the Fibonacci sequence. This helped balance the workload across the micro-teams, ensuring no one was overwhelmed during a sprint.
A standard User Story in our workflow looked like this:
- Title: A direct summary of the feature.
- Description: The value proposition (“As a user, I want to… because…”).
- Acceptance Criteria: Clear conditions for a task to be considered “Done” (UI details, logic, architecture, or specific technologies). I kept the technical constraints flexible, trusting the developers’ proximity to the code.
- Mockups: Visuals tied directly to the story. All mockups were accessible in a shared Figma project so everyone could see the big picture.
- Notes: Additional information that is useful for the successful completion of the development such as links to previous stories that needed to be finished first, and future stories that would rely on this current task.
Leading Without Authority #
As a PO in a university team, you don’t have absolute authority. You have to be smart and empathetic in your communication. You will inevitably face pushback or be asked to justify certain decisions. Therefore, every choice you make must be well-thought-out, highly rationalized, and clearly explained.
We structured our entire development process into an 8-week cycle, split into four 2-week sprints. The initial sprints focused heavily on base infrastructure and critical features. The final sprint served as a buffer to integrate the work of different micro-teams, fix bugs, deploy the Minimum Viable Product (MVP), and finally implement those highly requested “nice-to-have” features that wouldn’t bottleneck the core product.
Figure 2: 8 weeks later: transforming ambiguous ideas and extensive backlogs into a shipped product.
Conclusion: The Growth Beyond the Product #
Stepping into a team leadership position was, without a doubt, a pivotal moment in my evolution as an engineer and product thinker. I learned that guiding a project isn’t about giving orders; it’s about acting as a facilitator. It’s about clearing roadblocks, bridging the communication gaps between different skill sets, and empowering the team to deliver their best work.
Seeing our product successfully launch was an incredible reward, but the most enduring takeaway was the personal growth. Navigating the delicate balance between business constraints, design needs, and technical realities shaped my perspective in ways a traditional academic assignment never could. Ultimately, a product’s success relies heavily on the cohesion of its team, and learning how to foster that environment was the true highlight of this journey.