Tenets for Effective Product Management (Interspersed with My Opinions)
Spend 95% of your content-creation time on external-facing material
If you’re building an application for external users (usually the case), greater than 95% of the time that you spend on documentation should be for EXTERNAL consumption. I have a long-standing hypothesis that a company’s chance of success (and longevity) is inversely related to the number of Confluence pages (or SharePoint sites) that they create. I’ve worked at way too many unsuccessful companies where this principle was inverted. Teams of people wasted an unfathomable amount of time and energy creating page after page of internal-use documentation for products, scripts, science, and technology that never saw the light of day. Refocus all of your efforts on creating public-facing documentation. This brings me to my next point…
If you’re creating decks in PowerPoint, Keynote, or Google Slides, then you’re not doing Product Management
Now, you may have to create decks in order to keep your job, but if you’re doing it more often than not, that’s an excellent sign that leadership at your company doesn’t understand what Product Management is or how our time can be used most effectively. Try to convey this as often as possible to anybody that will listen. Once again, spend 95% of your time on external-facing documentation, including user docs, long-form content (i.e. blog posts), release notes, etc.
Slack less and Huddle more
If you find yourself typing more than a few words or a sentence in Slack, click on the Huddle icon instead: talk to your coworker(s) face-to-face and share a screen with the goal of coming to a shared understanding of whatever it is that you’re talking about. The original Agile Principles stated that the most efficient and effective means of communication is face-to-face; in today’s world, that means a Huddle rather than a Slack. You’ll save yourself an immense amount of back-and-forth time while strengthening relationships with your peers.
Don’t accept or promote the use of productivity-draining software
If you get an interview with a company and they send you a Microsoft Teams meeting or a Zoom call, decline the invite and move on. Why? You can tell a lot about a company by the productivity (or counter-productivity) tools that they use. Any company using Microsoft products (aside from Visual Studio) is willing to take a 30% hit on employee productivity straight outta the gate. That's a clear sign that there'll be a lot more red tape, inefficiencies, and processes for process's sake going forward. They’re living in the Stone Age, and your time there will be frustrating. Similarly, if the word "PRD" comes up at any point in the interview, politely decline moving forward. I haven't written a PRD since 2013; the concept of a PRD in software is outdated and conceptually flawed... it always was. I only mention this because I recently saw a LinkedIn post in which someone was providing "best practices" or similar for PRDs. The "best practice" for PRDs is to refuse to ever write one in the first place.
Create as FEW tickets as possible
Resist the urge to create a ticket to track every piece of work. Push back EVERY time someone says “let’s break this down a bit more.” NEVER create technical tickets. Refuse requests for sub-tasks and don’t allow anyone on your team to create them. Again, focus on face-to-face communication to arrive at a shared understanding of the desired outcome; this ALWAYS works better than detailed documentation and ticket proliferation. It has the additional advantage of making your backlog much easier to manage and prioritize. It’ll help if you get really good at writing concise user stories (in the Agile/Scrum format) with clear acceptance criteria. Another great option is wireframes (Moqups is by far the best) and videos (e.g. Loom) to explain what you need. AI tools can be very helpful with this too, but that would require another complete post. Note: You’ll have a lot more luck with this if you hire exceptionally talented teammates. I explain the benefits on doing so in this article.
Be averse to creating “Sales Enablement” material
This is especially true if the material that you’re being asked to create is internal-facing (i.e., in Confluence, SharePoint, Wikis, etc.). Instead, create public-facing documentation for your product marketing website, create onboarding videos for users, develop quickstart guides, create clickable walkthroughs and embed them in your application, create “pricers” and pricing tables on your product marketing website, and integrate them with Stripe for payment processing, and create blog posts and product release notes that highlight use cases, features, and functionality. Once you have sufficient content, use Loops to create automated drip-onboarding workflows for both internal and external users; provide appropriate content for each of your workflows. If you do it this way, your content will be reusable, componentized, versionable, and you won’t be trapped on an endless treadmill of internal-only content creation and updates.
Pick one wireframing tool and get really good at it
I’ve tried everything that has ever been created. Moqups is the best, by far, for Product Management; i.e., conveying concepts, functionality, workflows, UX expectations, and information architecture. Keep everything in grayscale and never include any visual design elements (or people won’t notice anything else). You should strive to be as fast as you are at hand-sketching with a pencil and pad. It’s a realistic goal. There are a lot of new options emerging with AI, but that’s another topic. Just pick one tool and get really good at it.
Rebel against the waterfallization of Scrum
SAFe is a four-letter word, and LeSS isn't more. No good comes out of institutional scaling of Agile principles or Scrum practices & ceremonies. Spotify’s model worked for them, but it won’t for you because you’re not Spotify. The “need” for scaling Agile arises due to 1. Built-in dependencies between tightly coupled software systems, and 2. Lack of adequate conveyance of vision by leadership. Systems and processes do not solve architectural boondoggles in software any more than Gantt charts solve lack of vision. I could go on about this for days, but I’ll keep it short and sweet for now.