3 Surprising Takeaways from My First 6 Months as a Product Manager at DSTA
Six months ago, I joined DSTA as a Product Manager (PM) within the Information Programme Centre (PC), focusing on digital products designed to combat disinformation and misinformation online. (You may read more about our work here.)
Reflecting on the past six months, it has been enlightening, particularly in understanding the product management culture in my team. I entered with certain expectations about the corporate structure and my role, but found the reality to be quite different. Here are three takeaways from my early experiences that illustrate the unique challenges and opportunities of a PM in this environment.
Disclaimer: This article reflects my personal experiences as a Product Manager at DSTA and should not be taken as representative of the organization’s official policies or the experiences of other staff.
Takeaway 1: DSTA is a large entity that surprisingly maintains a startup-like culture within its product teams
DSTA is a large organization, with 18 PCs and over 3000 staff. Each PC operates uniquely, with different delivery cadencies, processes, and team structures, leading to very different experiences. In Information PC, we work with Web App-based analytical systems with a high sprint cadence, in order to keep pace with rapidly evolving threats.
Given the organization’s size, I thought that product teams would function in a way more similar to those of large organizations. However, I was surprised to find a culture more akin to startups and medium-sized enterprises in my department.
PM roles and practices vary significantly across small, medium, and large companies, spanning six key dimensions: Scope, Process, Ownership, Agency, Impact, and Network. Ketan Nayak, a former product lead at Dropbox, comprehensively outlined these dimensions in his blog post for Product School. I will use his framework as a basis to analyze and describe Product Management in my team.
Dimension 1 — Scope: Range of responsibilities and involvement in product-related tasks
In my team, our scope of responsibilities as PMs is extensive, similar to what you might find in smaller and medium-sized organizations. We receive support from designers and developers, but actively engage in user research and directly market to our users in other public agencies. What industry might term as sales-led growth or guerilla testing, we call Ops-Tech. Ops-Tech ranges from DSTA engineers supporting active operations alongside MINDEF/SAF users using whatever tech can be thrown at the problem, finding threats alongside Ops users, and then making necessary improvements to our system to detect new threats and adversarial tactics, techniques and procedures (TTPs).
Additionally, we conduct industry and comparative research to inform strategic decisions about product development. Senior PMs also engage with external stakeholders from both the public and private sectors to explore meaningful collaboration opportunities — responsibilities that are often associated with business development or corporate strategy in larger organizations.
Dimension 2 — Process: Presence of established workflows and decision-making structures for product development
In my team, our process aligns somewhere between those typical of small and medium-sized companies. Our pace of work is fast, driven by the need to adapt quickly in an emerging and swiftly changing field. It is crucial to quickly ship products, learn from real-world feedback, and iterate improvements. In fact, some of us are focused on rapidly producing proofs of concept, prioritizing speed to test various hypotheses, which leads to a more unstructured and expedited process.
Dimension 3 — Ownership: Extent of control and influence over product areas or features
In my team, the level of ownership we have mirrors what you might see in small to mid-sized companies. Each of us is responsible for significant portions of the product, although the size of these “significant portions” varies with the complexity and scale of the product in question. For example, if our core product were Google Search, I might oversee a module as expansive as Google Maps, while my teammates might handle Google Travel and the main Google Search functionality. Although our components are different, they are interconnected, and we collaborate closely to ensure the overall success of the product. This ensures that when users search for directions on Google Search, the Maps module seamlessly appears at the top of the search results.
Dimension 4 — Agency: The initiative and ability to effect change within an organization
PMs with a high degree of agency thrive in our team. Our leaders are supportive when we proactively identify meaningful issues and take the initiative to resolve them or propose solutions, enabling us to drive significant changes.
Dimension 5 — Impact: Magnitude of influence a PM has on the product and its users
In my team, we handle a high scope and have significant ownership, leading to deep impact. For our “B2B” products, the breadth of impact is usually low as the products are built for specific, small user groups from other public agencies. However, we can expand our impact by strategically enhancing or adapting features for use across different departments or user groups.
For some of our “B2C” products used by the public, the breadth of impact is substantial, although the depth of this impact varies — mature products may only require minor enhancements, while developing a new product or feature from scratch offers more depth of impact.
Dimension 6 — Network and Brand: Opportunities for professional connections and the impact of organizational reputation on one’s career
At DSTA, we can establish deep relationships within our teams and broaden our networks through DSTA-wide training programs and activities that encourage cross-departmental connections. Additionally, our engagements with diverse external stakeholders extend our networking opportunities beyond the organization to international industry players, research institutes, and government partners.
Takeaway 2: Product management extends beyond feature ownership in my team, enabling us to embrace roles as outcome owners and facilitators
Initially, I understood that the role of a junior to mid-level PM primarily involved managing specific product areas — defining requirements, collaborating with developers, iterating on products, and ensuring their success. As PMs advance in seniority, they naturally take on more strategic responsibilities. This perspective was shaped by my own experiences and supported by industry discussions and job descriptions. However, joining my team at DSTA has expanded my perspective.
Unpacking the Unique Scope of PM Roles in My Team
Upon joining the team, I encountered the familiar responsibilities of a Product Manager but also roles that diverged from my previous experiences.
PMs here manage not only direct feature development but also undertake broader, more strategic initiatives. For example, some PMs act as “consultants” for other government entities, helping to increase efficiency of workflows with tech or promote the adoption of new technologies — roles that underscore our position as a key tech arm of the government.
I also observed that some PMs, despite being tasked with specific features, had limited decision-making autonomy. Their responsibilities primarily involved gathering inputs from other PMs working on related modules and overseeing the successful implementation of these features, focusing more on coordination and support rather than direct ownership.
Deciphering My Team’s Diverse PM Roles Through the Product Organization Matrix
Initially, I found it challenging to reconcile these diverse PM responsibilities with my conventional understanding of a PM’s work. This perspective shifted when I discovered the Product Organization Matrix from Reforge, created by Ravi Mehta, former Chief Product Officer at Tinder.
This matrix categorizes PM roles into four distinct types — Outcome Owner, Outcome Facilitator, Feature Owner and Feature Facilitator — illustrating the adaptability of PM responsibilities from full ownership to collaborative facilitation. Each role is designed to meet different organizational needs and differs by focus areas and levels of accountability within product management.
Referring back to my earlier observations, PMs who lead initiatives beyond direct feature development align with the roles of either Outcome Owner or Facilitator. For instance, a PM driving the adoption of technology like ChatGPT across a department for increased work efficiency focuses on the clear outcome of increased adoption, with the specific actions to achieve this being more flexible and not necessarily tied to feature development.
In the other scenario where the PM seems to own a feature but primarily coordinates requirements among other PMs, their role aligns more with that of a Feature Facilitator. In this capacity, they are integral to the feature’s integration and success, yet the responsibility for the outcome is collectively shared among all involved parties, not just the facilitating PM.
Leverage the Matrix for Better Role Understanding and Evaluation
Beyond helping me clarify my role and resolve initial confusion, the Product Organization Matrix ensures that all PM outputs, including those from facilitative roles, are properly accounted for. This contributes to fair evaluations of our work. It is heartening that our product leaders have recognized the matrix’s value in enhancing role clarity and fully acknowledging the breadth of our contributions.
Takeaway 3: Core PM competencies are not only essential for standard PM tasks, but are equally important for other roles required of us as PMs in my team
In the first two takeaways, we have explored how PM roles in my team cover a wide scope and involve high ownership. Despite some distinctions from PM roles found elsewhere, the core PM Competencies highlighted by Ravi Mehta— such as product visioning, business outcome ownership, and stakeholder management — are not only relevant but crucial for the varied work we do. For instance, when engaging with other public agencies, PMs in my team must balance the interests of these agencies with our own objectives, effectively utilizing their skills in managing and aligning stakeholder interests.
Although I am still an early-career PM, I am given opportunities to apply these competencies in diverse contexts that go beyond traditional PM tasks, or work on tasks that are typically reserved for more experienced PMs elsewhere. This not only helps me enhance my existing skill set but also enable me to develop new competencies, particularly in areas like product strategy and stakeholder management.
This breadth of responsibilities makes our team ideal for PMs seeking to apply their skills in scenarios that go beyond the usual confines of product management roles. Proactive and adaptable individuals will find this environment enriching and can look forward to significant professional growth.
My first six months as a PM at DSTA have been enriching, and this article reflects on the insights I have gained. I hope these insights offer a clearer understanding of product management within my team and provide some valuable perspectives for early-career PMs navigating their own paths in this field.
Special thanks to my manager, Lorenzo Ong, who has been instrumental in spearheading product management at DSTA, creating fantastic opportunities for us, and consistently providing insightful advice.
Thank you for reading! I welcome your thoughts on product management in different organizations or any alternative perspectives you might have on my observations.
