post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Product Management

Sunday Rewind: Whose job is it anyway? The rise of Product Ops and why it deserves to be an independent function

Guest Post

Creating metrics that matter

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

How much are product managers getting paid in 2024?

Leading product ops at Delivery Hero with Koen Dubelaar

Connecting fans to creators at Spotify (Dariusz Dziuk, Product Lead, Spotify)

“You’re not as competent as you think” 5 lessons from Ken Chin on navigating a product career (CPO, Spark Networks)

Everything wrong with the product management job market. And how to fix it

Tremis is a senior product manager with work experience in the United States, Europe, the United Kingdom, and an avid writer about topics related to product development. Tremis is also the Executive Editor for Product Coalition. To find out more, visit tremisskeete.co.uk.

Tremis Skeete

<p>My journey to product management was not what you might expect, but then again, maybe you would. I studied accounting and computers in high school. At 19 I got a job as a computer technician and by 21 I was a computer science major. I then got a job on campus as a network administrator.</p>
<p>Three years later I became a web application engineer at a startup that built software for military and private industries. I redesigned the internal and public web properties and was promoted into my first “product leadership” role. I became director of communications, leading the development of intranets and web applications.</p>
<h3>From Startup to Enterprise</h3>
<p>A job at a startup means a lot of responsibility. I found I had to be creative, open-minded and motivated to work outside my job description to succeed. Challenges aside, I enjoyed the close-knit teams and easy access to upper management which enabled quick decision making. So you can imagine the culture shock I experienced when I took a graphic designer position with a large technology organization in New York City.</p>
<h3>Designers vs Developers</h3>
<p>The work culture in this large organization was unlike anything I’d ever experienced. With over 300 people in total &#8211; 50-60 developers, and a team of four graphic designers (you read correctly&#8230; four) &#8211; the development process was saturated with bureaucracy and friction, with little or no camaraderie between designers and developers. In fact there was tension between designers and developers due to cultural and language differences (most developers were Indian and Asian, the other three designers were white Americans, and I am British West-Indian).</p>
<p><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2017/12/270009c2-c181-4e0f-b6b5-d60fd885eea4_pasted20image200.png" alt="" /></p>
<p>Senior managers responsible for establishing business processes decided project managers and developers would get more face-time with end users to do design walkthroughs and ensure functionality was built to desired specifications. My fellow designers were unhappy with this decision.</p>
<p><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2017/12/d8ea3984-ef13-4831-9b11-30654b1bf224_pasted20image200.png" alt="" /></p>
<p>They believed developers should not be involved in the user interface design process and that they should have full control over designing the user experience. They also said that end users didn’t know what they wanted unless we, the graphic designers, showed it to them (they were Steve Jobs fanboys). Tension between designers and developers was palpable. I became a designer who attempted to resolve this problem.</p>
<p><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2017/12/cad0122c-5e9a-4f0b-a8c1-cc3abe062800_pasted20image200.png" alt="" /></p>
<h3>Developers are Also our Customers</h3>
<p>We had conversations with the developers about their design challenges. They were happy to share these with me because we had built a good rapport. I shared my software development knowledge with them and we established mutual understanding and trust.</p>
<p>During these conversations there was one recurring topic. Whenever developers requested UI templates, the creative design team responded with templates that looked beautiful but which could not be easily adjusted unless designers were directly involved. But the developers needed to work quickly, use agile methods and be able to adjust the UI without the need to call on designers each time.</p>
<p>I came to realize that, as a designer, I was building software for customers &#8211;  the end users &#8211; but it was also our responsibility to know that developers are also our customers. We should build UI templates that work well for end users <em>and</em> developers. These adjustable component-based UI templates that the developers described is what most of us today would call “design systems”.</p>
<p>We then pitched an idea to a senior manager about a design system that would adhere to the organization’s software development policies, style guides, and help developers and designers meet organization and customer goals. We presented an alpha prototype I’d created as an experiment, to provide context. The manager gave us the green light, and the developers and I formed a product team. That is when I became a product agent.</p>
<h3>The Product Agent’s Mission</h3>
<p>An agent is someone whose mission is to get things done on behalf of others. My mission was to be whatever was necessary to ensure that the product team was included in the design process, and, the design system was built to benefit everyone. By “everyone” I mean:</p>
<ol>
<li>End users</li>
<li>Stakeholders</li>
<li>Senior management</li>
<li>Designers</li>
<li>Developers</li>
</ol>
<p>To accomplish this mission, I decided to welcome as many ideas as possible from my team. The trick is to remember that once you can manage the flow of ideas generated by your team, your team can discover the right ideas. To manage the flow, I adopted a strategy which included the following:</p>
<ol>
<li>Practise the art of “no ego”</li>
<li>Articulate strategies and plans</li>
<li>Articulate objectives and goals</li>
<li>Remember that you can’t stop the flow of ideas, but you can steer.</li>
</ol>
<h3>The art of “no ego”</h3>
<p>There is no such thing as not having an ego. so in the ideation phase, having “no ego” while working with the team meant I needed to shift my perspective. I needed to shift my train of thought from feeling intimidated or irritated by other people’s ideas, to a mindset where I sought to be inspired by each and every idea. You shouldn’t pretend you are not afraid or ignore your fears, because we will all feel intimidated by others from time to time when it comes to the work we do as product people. Instead, practising “no ego” means leveraging your fear to use it as fuel for your motivation in carrying out your mission.</p>
<p>It’s possible to silence your ego and create an alter ego. Think of your alter ego as another way of saying: “The best kind of person you must become in order to ensure your team works together to build the right thing.” By communicating with your team as your alter ego, you can focus on how to steer your team towards what is the right product to build for your customers.</p>
<h3>Articulate Plans, Strategies, Objectives, and Goals</h3>
<p><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2017/12/34e6fbaf-c69b-4e49-92dc-ebcb2902f1b3_pasted20image200.png" alt="" /></p>
<p>To understand clearly what kind of design system to build, it was essential to articulate strategies and plans to the product team. It was also important for the team to understand the importance of articulating, rather than just communicating. Product agents need to communicate not just the right words, but the contexts and meanings behind them. By doing so, everyone can have a shared understanding of the <strong>plan</strong>, which is the <strong>steps you take and tasks you perform to meet an objective or goal</strong>. The <strong>decisions you’re willing to make based on the outcomes of your plan </strong>&#8211; that is your <strong>strategy</strong>.</p>
<p>To ensure the team understood how their ideas affected the strategy and plans, I created a mental model (see above) designed to help us guide conversations in order to meet objectives, goals, understand pain points, team roles, customer roles, and address the right items at the right opportunities. When speaking about objectives and goals, keep in mind that in this situational context, a <strong>goal</strong> is <strong>what you want your customers to know, think, and feel about your product</strong>. An <strong>objective</strong> is <strong>what your product needs to have in order to meet that goal</strong>. Keeping your goals and objectives in mind means also keeping in mind <strong>your customers, action steps, and deliverables</strong>.</p>
<h3>You Can’t Stop the Flow of Ideas, but you can Steer</h3>
<p>According to Jon Bell’s McDonald’s theory: “People are inspired to come up with good ideas to ward off bad ones.” To me this means that you should always be ready to discuss bad ideas, so you can steer the conversation towards better ones. Steering is about being inspired during iterative processes, moving quickly, getting the rough ideas out there, and revising over and over again. This process allowed the developers to be a part of the process and share credit.</p>
<h3>Conclusion</h3>
<p>It’s been some years since I moved on from that large organization. So what happened to the product team and the design system? I have it on good authority that the design system is still being used by many developers. The developers have been empowered with the means to get their job done, and end users and stakeholders have expressed great satisfaction with the applications that have been built using this system.</p>
<p>What about the other designers? They were surprised to discover that I took the initiative, but once the shock went away they saw the value and possibilities in component-based UI design. They also realized creative ways to design additional features. They were impressed. Mission accomplished.</p>

core/freeform

What good product design looks like – Miguel Fernandez (VP of Product Design, Slack)

The Product Agent: Managing Ideas on a Product Team

Tremis Skeete