Military officers interested in moving into technology should consider careers in Product Management. There are strong parallels between the roles and product management requires many of the skill sets that effective officers have developed in their time in the service. But believing that you would be a good product manager and actually getting your foot in the door for an interview is another story.
Solid Pods (Personal Online Data Store) are an open source project from the efforts of Sir Tim Berners-Lee (creator of the original internet) with a goal of re-decentralizing the internet. This project is still in development, I think it has a lot to offer in order to help make developing web applications easier and safer for the developer, user, and society at large.
Solid provides a web standard’s compliant API to provide the owner of the pod with an identity (WebID), storage (document store), and relational language for data. Applications can be built to access and store data in the pod, rather than in storage systems owned by the application.
You don’t want to store your customer’s data
In the beginning there were web pages and they were good. Then customers wanted to have web pages that had data that was specific to them. The web portal was born it works but from a privacy standpoint it has been going downhill for customers and the companies that are storing this data.
The conventional wisdom is that storage is cheap, which makes it easy to store data about your customers. In today’s world you should be asking yourself, just because I can, should I. The real cost of data is in the liability of keeping it. The average cost of a data breach in 2019 was $3.29 Million.
Even if you manage to keep all of your data under lock and key, you will face a growing number of privacy process challenges for the data. Right now any EU citizen can make a subject access data request to you through the General Data Protection Regulation (GDPR). Each of those requests are costing businesses on average $1400 per request to process.
It isn’t just the EU other countries and states are moving in that direction. Brazil’s privacy law closely matches the GDPR to stay inline with Portugal. Japan has adopted legislation that is also very similar to Europe. In the U.S. California has adopted the California Consumer Privacy Act (CCPA) and 40% of Americans are covered by some form of state privacy law. There is significant debate what shape a federal privacy law will take, but that is more about what type of law we get rather than if there will be a law.
If the actual administrative, legal and reputational risk of storing data isn’t enough; having large stores of data increases national security risks as well. As recently highlighted by the Cyberspace Solarium Commission report every website that becomes a target decreases the overall national cybersecurity posture. We already have large examples of IT systems at Marriott being attacked by likely state intelligence services in order to get a rich set of data about the travel patterns and personal preferences of Americans and particularly the U.S. government employees that stay in their hotels for work and pleasure.
You might tell yourself, this won’t happen to me. I run a tight ship and take security seriously. Don’t count on it. Every web connected anything is open to attack from well financed, trained and organized state and organized crime groups. There are more smart people out there with a motivation to attack you than there are engineers you can hire to protect yourself. Read enough Krebs on Security and you will realize that breaches happen to everyone, they happen to large smart companies and the folks who thought they were small enough to fly under the radar.
The safest way to live is to have nothing to steal
How do Solid Pods help solve this problem? Right now identity on the internet looks a lot like this:
No individual has a standardized identity on the internet or storage system, each website forces you to create a new one every time. Even worse, many web-sites have to implement storage of these identity systems from scratch. Many of the big players (Google, Facebook, Apple, Microsoft, etc.) have allowed you to federate authentication using their existing identities, but that requires you to share data with those companies about who is using your service, frequently feeding them the data on how to compete with you. You can (and probably should) pay for someone else who has implemented identity systems already (Auth0, Okta, etc), doing it yourself is not advisable.
Regardless of how you implement it, every web-site you go to forces you to create another identity, password and slowly collects some amount of data about the user. That data is likely repeated over and over for every website. You enter your shipping and billing addresses from every commerce transaction, then have to update those when you move. I moved more than a year ago and am still finding websites that still have my old address listed. I still get mail at my house for the old owners. Your data is in bits and bobs all over the internet.
I love 1Password (really you should use a password manager); but the fact that I have a product to keep track of and secure 389 logins that I’m aware of on the internet right now, is an indication that the internet is broken.
It. Doesn’t. Have. To. Be. This. Way.
In a world with Solid the internet instead looks more like this:
You have one identity, provided by your solid pod. When you go to a web-site you grant it permission to show you your data from your pod. When you leave the website, they no longer have access to your data. Even better when you go to a new website, you don’t have to re-enter all of that data, you have already filled in the shipping address field on your identity, applications can simply read that.
The underlying technology is still early and has some clear growing that it needs to do. But I think it offers an interesting potential solution for both enterprise and consumer software.
In the Enterprise data owners get a big step forward in data ownership and control. You have to trust your SaaS vendor less when you own and control the data. For developers it provides an opportunity to move enormously difficult parts of every compliance attestation, outside of your compliance boundary.
Right now if you want to avoid getting a PCI attestation, you use Stripe, you never touch the credit card data and avoid a boat load of problems. If you applied the same theory to user authentication, authorization and data storage, you could eliminate entire categories of compliance problems.
- Encrypting data at rest, nope you never touched the data.
- Backups, nope never had anything to backup.
- Backup restoration testing, all I need to do is redeploy the single page app.
A smaller compliance boundary means that you can gain attestation with less effort for significant payoff. Many enterprise customers won’t talk to you unless you have at least an ISO-27001 cert, and that is the bottom rung. Every standard you add on opens your potential customer base more.
On top of that you no longer need to invest in building or integrating then operating and monitoring the systems that are required for authentication, authorization and storage. That means you can move faster on core product improvements and either charge less or have improved margins.
For consumers software Solid allows you to significantly minimize the regulation of consumer privacy on your business. In the ideal world, when a user shows up to your site, the only thing you know about them is the address of their pod, even that could live in their browser.
Similar enterprise software you now get to focus on your product rather than lots of web-scale infrastructure and the engineers required to maintain that infrastructure. Ben Thompson of Stratechery has written extensively about the impact of regulation to reinforce the position of the Big Cos. The short version is that everyone collects data on their users, the data gets mis-used by the big companies, governments create regulations with the intent of making sure the big companies behave and user privacy is respected. The outcome however is that you need a lot of infrastructure, legal and investment to follow those rules. Meaning big companies are in the best position to make those investments and everyone else goes away because they can’t afford to follow the regulation and build a product.
If you don’t have any data, you don’t have to pay as many lawyers or compliance engineers, and you aren’t actually running the infrastructure to store the data, then your operations cost just went way down. Lower costs make you more competitive. Yay!
There are some other tricks in the Solid universe. If a user has all of their data in one location multiple apps can re-use and enrich the same data. This helps solve some portability problems and potentially decrease time to value for your users. There is also a rich and extensible language for defining relationships between pods. Meaning you can create social relationships without having to tap into Facebook.
The way ahead - Chicken meat Egg
Solid might be nice tech but it is going to need some decent applications. Before people use the application they will need to get a pod. There are currently some applications, but most of them appear to be more playground work than production ready.
In order to use the applications, users will need to have a solid pod. The pod providers are going to be picking up the responsibility for securing your data, I personally would want the pod provider to have their compliance ducks in a row. My personal preference would be to know that my pod provider can’t read the contents of my pod, that all pods are cleanly separated, plus all of the backup and restoration things.
There are currently a smattering of providers, but none of them quite feel like something I would pay for yet. Inrupt’s own service lists itself as a prototype. ¯\_(ツ)_/¯
I could see some of the following companies being strategically aligned with adding a pod hosting option to their services.
- Identity Provider solutions (Auth0 or Okta) are already in the authentication technology space and already have strong relationships with the enterprise software landscape. Adding Solid would be an extension that would allow them to serve more of their customer needs. And provide an OAuth + Solid developer pattern in addition to an OAuth + SCIM pattern that is common today.
- Password Managers (1Password, LastPass, Dashlane) are already in the business of selling users secure containers for their most personal data. They also have some Enterprise and SMB relationships. Add Solid would extend their ability to contain more data than just passwords for their users.
- Apple has made a particular strategic lift in the past several years to make themselves the company that cares about your privacy and data. Most significantly they added Sign In with Apple for login. Adding Solid support would allow them to add a developer layer on top of iCloud storage that provides more privacy protection than an obfuscated user id.
- AWS/Azure/GCP - If you were a business looking for a Solid provider, then you would probably hope that one of these companies provides it. They probably already hold a bunch of data for you, and they are highly competent at running data centers.
I made a career transition into Product Management four years ago. Prior to starting my first role at Splunk as a line level Product Manager my previous experience was in the U.S. Army. I didn’t know that product management was a career field option when I started my job search, and as I look back on it I’m amazed I got any interviews at all. I had no meaningful experience building software, and I made some blind assertions that I had qualifying experience as an Army Officer. I still maintain that those assertions holdup, and I think most companies would do well to hire more Junior Military Officers as Junior Product Managers.
Once I managed to find a job, I’ve faced the task of educating myself on the craft of product management. I’ve long been a person who learns well through self-study. I blame the Army that taught that professional development was 1/3 on the job, 1/3 in the classroom, and 1/3 personal development. It’s also possible I’ve just always been a nerd.
Below you will find a list of books, blogs and podcasts that I’ve read and strongly recommend. If I were hired or tasked to start an associate product management training program at a company. Most of the content here would constitute my curriculum. Now you can have the benefit of that without having to listen to me lecture.
But what about all those posts on Medium?
I tend towards books rather than the plethora of Medium posts because I think you can find lots of half-baked things on medium. I personally have published on Medium in the past (and now write here using GitHub Pages), and opined on my views of what product management is to me. But I’m a bit of an institutionalist and I tend to give some more credence to folks who gone through the effort of getting something formally published. Continuing to read on the internet is great, but I think it can be a bit hard to follow if you are trying to establish some foundations.
Affiliate Note: Where I link to books on Amazon, I am using affiliate links, because they might as well pay me for sending traffic their way. I strongly recommend checking your local library for copies of the books.
What is the job
This section includes several great books to get started understanding what product management is. If you haven’t worked somewhere that has product managers as a role, start here. Also start here if you feel like people keep saying things about what product managers should be doing and they don’t all quite make sense.
From the author:
To stay competitive in today’s market, organizations need to adopt a culture of customer-centric practices that focus on outcomes rather than outputs. Companies that live and die by outputs often fall into the “build trap,” cranking out features to meet their schedule rather than the customer’s needs.
In this book, Melissa Perri explains how laying the foundation for great product management can help companies solve real customer problems while achieving business goals. By understanding how to communicate and collaborate within a company structure, you can create a product culture that benefits both the business and the customer. You’ll learn product management principles that can be applied to any organization, big or small.
Andy’s take: I think this is probably the best book I’ve read on what Product Management is. It explains it clearly if you are learning how to interface with product management for the first time, if you are trying to build a product management organization, or want to understand how product management organizations are structured and organized to be effective and focused on customer problems.
If you want to get the essential understanding of what product management is, start here.
From the author:
In today’s lightning-fast technology world, good product management is critical to maintaining a competitive advantage. Yet, managing human beings and navigating complex product roadmaps is no easy task, and it’s rare to find a product leader who can steward a digital product from concept to launch without a couple of major hiccups. Why do some product leaders succeed while others don’t?
This insightful book presents interviews with nearly 100 leading product managers from all over the world. Authors Richard Banfield, Martin Eriksson, and Nate Walkingshaw draw on decades of experience in product design and development to capture the approaches, styles, insights, and techniques of successful product managers. If you want to understand what drives good product leaders, this book is an irreplaceable resource.
- The Authors are Pillars of the product management community. As the collective founders of Mind the Product they represent an enormous mind-share about what it means to build products in today’s software ecosystem.
- I love that this book takes a broad vision of what a product leader is. There can be a tendency to draw sharp lines between people by title and what they do. (Engineering Managers and Engineers should stick to engineering and Product Managers think about product things!) This book is more inclusive and I think represents reality better, Product Managers, Engineers, UX/UI, Docs are all part of the Product Leadership team of a company.
- They do a great job talking about what it means to do product at different sized and staged companies. Startups, mid-sized companies, and enterprise companies all have a very different feel, they work in different ways. Reading this section of the book if you are trying to break into product management is a good way to understand what kind of company you are looking to apply to.
From the author:
If you’re new to software product management or just want to learn more about it, there’s plenty of advice available—but most of it is geared toward consumer products. Creating high-quality software for the enterprise involves a much different set of challenges. In this practical book, two expert product managers provide straightforward guidance for people looking to join the thriving enterprise market.
Authors Blair Reeves and (Benjamin Gaines)[https://twitter.com/benjamingaines] explain critical differences between enterprise and consumer products, and deliver strategies for overcoming challenges when building for the enterprise. You’ll learn how to cultivate knowledge of your organization, the products you build, and the industry you serve.
My first (currently only) experience in software is in Enterprise Software. So I was thrilled to learn that there was a book specifically about building products for Enterprise Software. In this case Enterprise Software is referring to the companies you are trying to sell to, not so much the type of company you are. There are plenty of startups and mid-sized companies that are trying to sell to Enterprise Customers. But selling to an Enterprise customer has very distinct sales motions, support requirements, cadences, that are, as far as I can tell, nothing like consumer products.
This book has a great overview on how to work with the many different parts of this process. Understanding who you are building for, how your organization works, how to think about your industry. Read this if you are going to be selling to companies, particularly big ones, rather than individual people.
As a final note I also like Blair, he’s got a strong twitter game, an occasional newsletter, and we’ve become somewhat Twitter friends. He has a much bigger following than me, but we’ve corresponded multiple times and he’s always genuine and smart. Be aware that his twitter goes overtly political quite often, which is fine with me, but truth in lending if you want just the product stuff.
Methods and tools
From the author:
User story mapping is a valuable tool for software development, once you understand why and how to use it. This insightful book examines how this often misunderstood technique can help your team stay focused on users and their needs without getting lost in the enthusiasm for individual product features.
User story mapping is by far my favorite design technique. I use it whenever I get the opportunity. I find that it provides a clear and easy way to communicate what the user is trying to accomplish. It helps visualize the flow, discuss sequencing and priorities and does a great job of drawing out missing steps. I also love that the technique is easy to explain and understand. It’s simple to implement, while there are tools out there to build a story map, I’ve also effectively built story maps in a spreadsheet so that I could project it when I’m working with distributed teams or multiple co-located teams in different cities.
Also Jeff Patton is a giant the industry, when he speaks or writes something I perk up and listen (see the recurring resources)
John Cutler is one of the most prolific writers I know on Product Management, his newsletter is further down the list of continuing education. At the time of writing he works at Amplitude which is a tool focused on helping Product Managers understand how users use their products. Working with his peers at Amplitude they’ve written this terrific guide to picking strategic metrics. Having a clear strategic metric can be incredibly grounding for a team and helps tremendously when you are trying to prioritize work with your teams. It gives you the magic power to say to a stakeholder a clear articulation of why you prioritized one thing over another.
Lean, Agile and DevOps
Most of the software development world will claim to apply some form of Lean and Agile methodology. You will never show up to a company that brags about their waterfall development methods. Some might admit that they are still transitioning or admit that there are constraints that prevent them from being more agile (government contracting struggles with this). But having a good understanding of what “Agile” is, will help you as a product manager.
At its highest level I tend to think of Agile as applying Lean principles to IT and software development. Lean was first developed by Toyota in their famed Toyota Production System. Encouraging continuous and early learning, small batches and empowering individuals throughout the system to point out defects and areas for improvement. Thankfully there are some great texts out there.
Foundational to Agile in software is the Agile Manifesto. It’s short and easy to read in less than 30 seconds, but like a zen koan, you can spend a lot of time thinking about and working on the implications. A lot of Agile is built upon the practices of Extreme Programing.
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
From the author:
How can we apply technology to drive business value? For years, we’ve been told that the performance of software delivery teams doesn’t matter―that it can’t provide a competitive advantage to our companies. Through four years of groundbreaking research to include data collected from the State of DevOps reports conducted with Puppet, Dr. Nicole Forsgren, Jez Humble, and Gene Kim set out to find a way to measure software delivery performance―and what drives it―using rigorous statistical methods. This book presents both the findings and the science behind that research, making the information accessible for readers to apply in their own organizations.
Readers will discover how to measure the performance of their teams, and what capabilities they should invest in to drive higher performance. This book is ideal for management at every level.
Don’t read anything else until you read this. Stop reading this page right now and read this book. I’ll wait, this book is that important. Almost nowhere else will you find such a definitive, clear and well researched book to demonstrate the actual measurable value of adopting Lean/Agile/DevOps practices in your software development. This book comes complete with years of research, flow charts and suggestions on how to avoid burning your teams out, develop software better, and deliver value faster.
The best part of this book is that they boil all of the knowledge down into four clear, measurable metrics that you can use right now in your business to understand how well your team and your process stack against the rest of the industry. Not only do these give you an understanding if you are a low, moderate, high, or elite team in the industry, they give you great chart to visualize how to get there.
Also follow Nicole Forsgren on Twitter, always smart things, sometimes funny things, and frequently things to remind you about blindspots in the industry for diversity and inclusion.
From the author:
Written in a fast-paced thriller style, The Goal, a gripping novel, is transforming management thinking throughout the world. It is a book to recommend to your friends in industry - even to your bosses - but not to your competitors. Alex Rogo is a harried plant manager working ever more desperately to try improve performance. His factory is rapidly heading for disaster. So is his marriage. He has ninety days to save his plant - or it will be closed by corporate HQ, with hundreds of job losses. It takes a chance meeting with a professor from student days - Jonah - to help him break out of conventional ways of thinking to see what needs to be done. The story of Alex’s fight to save his plant is more than compulsive reading. It contains a serious message for all managers in industry and explains the ideas, which underline the Theory of Constraints (TOC), developed by Eli Goldratt.
This novelization follows an auto parts manufacturer, as they struggle to streamline production and save the business. This text is foundational and classic. So classic that my father, a manufacturing engineer, read it as part of his college courses many moons ago. But it holds up. Look past the fact that they are talking about building car parts not software, for our purposes they are not significantly different.
From the author:
Bill, an IT manager at Parts Unlimited, has been tasked with taking on a project critical to the future of the business, code named Phoenix Project. But the project is massively over budget and behind schedule. The CEO demands Bill must fix the mess in ninety days or else Bill’s entire department will be outsourced.
With the help of a prospective board member and his mysterious philosophy of The Three Ways, Bill starts to see that IT work has more in common with a manufacturing plant work than he ever imagined. With the clock ticking, Bill must organize work flow streamline interdepartmental communications, and effectively serve the other business functions at Parts Unlimited.
In a fast-paced and entertaining style, three luminaries of the DevOps movement deliver a story that anyone who works in IT will recognize. Readers will not only learn how to improve their own IT organizations, they’ll never view IT the same way again.
This book returns to Parts Unlimited (from the Goal), and tells a story of applying the same lean principles that saved the manufacturing business to the IT department. This is a great primer on what DevOps looks like in application.
From the author:
This highly anticipated follow-up to the bestselling title The Phoenix Project takes another look at Parts Unlimited, this time from the perspective of software development.
The Unicorn Project, we follow Maxine, a senior lead developer and architect, as she is exiled to the Phoenix Project, to the horror of her friends and colleagues, as punishment for contributing to a payroll outage. She tries to survive in what feels like a heartless and uncaring bureaucracy and to work within a system where no one can get anything done without endless committees, paperwork, and approval.
One day, she is approached by a ragtag bunch of misfits who say they want to overthrow the existing order, to liberate developers, to bring joy back to technology work, and to enable the business to win in a time of digital disruption. To her surprise, she finds herself drawn ever further into this movement, eventually becoming one of the leaders of the Rebellion, which puts her in the crosshairs of some familiar and very dangerous enemies.
The Age of Software is here, and another mass extinction event looms—this is a story about rebel developers and business leaders working together, racing against time to innovate, survive, and thrive in a time of unprecedented uncertainty…and opportunity.
The final (or maybe most recent) installment at Parts Unlimited tells you the story of the evolution of their software development practices. The characters again learn to apply small batches, continuous integration and continuous testing to their application development practices. This is a great text to read what right should look like, as well as help you develop a sense of empathy for the developers on the teams you work with.
From the author:
“…the dominant paradigm for managing product development is wrong. Not just a little wrong, but wrong to its very core.” So begins Reinertsen in his meticulous examination of today’s product development practices. He carefully explains why invisible and unmanaged queues are the underlying root cause of poor product development performance. He shows why these queues form and how they undermine the speed, quality, and efficiency in product development. Then, he provides a roadmap for changing this. The book provides a well-organized set of 175 underlying principles in eight major areas. He shows you practical methods to: Improve economic decisions Manage queues Reduce batch size Apply WIP constraints Accelerate feedback Manage flows in the presence of variability Decentralize control The Principles of Product Development Flow will forever change the way you think about product development.
While product management is not project management (with a focus on throughput and timelines), a successful product manager will do a fair portion of project management as you manage the sequence of your backlog, work with the team to release work into development, and work on managing dependencies and handoffs when working on multi-team efforts.
This is not the most exciting read, unlike The Goal, Phoenix and Unicorn projects, it is a more academic discussion of principals and potential solutions to common problems when managing development queues. But if you work your way through this text you are never going to look at your development process the same way again.
From the author:
How well does your organization respond to changing market conditions, customer needs, and emerging technologies when building software-based products? This practical guide presents Lean and Agile principles and patterns to help you move fast at scale–and demonstrates why and how to apply these methodologies throughout your organization, rather than with just one department or team. Through case studies, you’ll learn how successful enterprises have rethought everything from governance and financial management to systems architecture and organizational culture in the pursuit of radically improved performance. Adopting Lean will take time and commitment, but it’s vital for harnessing the cultural and technical forces that are accelerating the rate of innovation.
- Discover how Lean focuses on people and teamwork at every level, in contrast to traditional management practices
- Approach problem-solving experimentally, by exploring solutions, testing assumptions, and getting feedback from real users
- Lead and manage large-scale programs in a way that empowers employees, increases the speed and quality of delivery, and lowers costs
- Learn how to implement ideas from the DevOps and Lean Startup movements even in complex, regulated environments
I’ve never highglighted more sections of a book for use later (well it is a close count between Accelrate, Prinicipls of Product Development Flow), but this is a great guide to not only making agile work at the one team level, but how to make large technology organizations work quickly, in small batches, to advance your goals. Must read if you are working in a bigger organization.
Product Managers spend most of their time communicating. You communicate with stakeholders to understand their needs and explain their plans, you communicate with your team to explain the business case for a feature and the users needs, you communicate with the sales and field team to explain what has been built and what is on the roadmap. Learning to communicate well is essential to good product management. Here are a few resources that I think have improved my communications skills.
From the author:
Annie Duke, a former World Series of Poker champion turned business consultant, draws on examples from business, sports, politics, and (of course) poker to share tools anyone can use to embrace uncertainty and make better decisions. For most people, it’s difficult to say “I’m not sure” in a world that values and, even, rewards the appearance of certainty. But professional poker players are comfortable with the fact that great decisions don’t always lead to great outcomes and bad decisions don’t always lead to bad outcomes.
The thing I took away from this book is learning to be clear about what you don’t know. Lots of people will expect or want the product manager to have all the answers. But there are always unknowns, we are always experimenting and making bets about what might work and what users might need. Even with good process we’ll always be guessing at some level. This book gives you some great tools to help understand how to frame your uncertainty and communicate it.
Blogs, Podcasts, and Newsletters
John Cutler - The Beautiful Mess - John Cutler is one of the most prolific writers on product management that I know of today. His newsletter is a great way to keep up without being overwhelmed by the stream of content on his twitter feed (which is also worth following, but hard to catch all of).
The Margins - Ranjan and Can write one of the smartest newsletters out there on trends in tech and its impact on society. Not really about product management at all, but always a great read to help product managers think about how the software they are writing might be shifting or moving with society and computing at large.
- Stratechery - Ben Thomson writes one public article and three subscriber only newsletter updates a week. With a focus on the business of software strategy, the impacts of his cornerstone Aggregation Theory, and breaking down the tech news of the week with an eye on the strategy or apparent lack there of the various companies making the news. Reading Stratechery regularly is like getting a business school education, without having to take 2-3 years and tens of thousands of dollars in debt. You unfortunately don’t get a fancy degree as a result.
- The MetaCast - Great podcast from very experienced agile coaches.
- Enterprise Ready - Podcast and Enterprise Ready - Website - These sites are incredibly valuable for product managers working in the enterprise software space. The podcast is a great set of conversations with enterprise founders and operators talking through how they found their ideas, how the started their companies, how they approach sales and support, I don’t think I’ve shared any single podcast to members of my teams as often as I do this podcast. The website is also valuable giving an enterprise PM a list of features that they can start checking off to make sure they are ready for the biggest customers.
- The Product Experience - The podcasting arm of the Mind the Product network. They cover a huge variety of different aspects of product management for different industries, different size companies. A valuable resource to help you discover new things that you might need or might not know existed.
Commuting is a pain. My particular commute is a multi-stage, adventure that can take an hour on a decent day and mind boggling amounts of time if something goes wrong in Seattle traffic. My spouse and I start by carpooling to our day-care, drop off a kiddo, then catch a bus into downtown, and finally walk across town to my office. Most of the time it works just fine. But it doesn’t take much to throw off the whole experience to a post-apocalyptic hell-scape of gridlock. In the past several years, we’ve seen car accidents and trucks full of bees or fish completely stop the major high ways and all of the side streets.
There has been much ink spilled and great gnashing of teeth over Facebook’s news tab and the inclusion of Breitbart as a “high quality” news source. I continue to be amazed that social media organizations have moved to help establish clear standards and certification for what counts as a high quality newsroom.
I don’t like conducting interviews. I would rather be interviewed for a job than interview someone for a job. If I have to choose between written and oral communication, I will usually prefer to write. I like async communication because I have time to think clearly and then commit to words what I’m thinking. I have a mild central auditory processing disorder, meaning an in-person interview pushes my limits of listening, and critically processing, and taking notes on answers in real time. Critical assessment of the candidate’s answer will probably be the functional task that drops.
I’ve been a product manager for three and a half years after being an Army officer for eight. Never in that time have I felt like I truly owned all of the products I’ve worked on. I’ve never had the final say in everything, and I’ve never sat to review that every single story met all of the acceptance criteria. Time, team dynamics, and the nature of working on large complex products precludes any single person from being able to exert that level of control. I’m largely in agreement John Cutler about the overload of product manager responsibilities and the danger of centralizing them. I’m here to propose that product managers should think of themselves as good scouts rather than all controlling owners of the product.
Watching the aggressive use of Facebook, Twitter, Reddit to disrupt American political and social systems makes me think that organizations above a certain size should have a Chief Devil’s Advocate on their team. This exec should be focused on every way that your product could be used for misdeeds.
I listened to a great episode of Deliver It on DevOps for Product Owners and a comment by the Lee Janson that you don’t have to have perfect DevOps practices right away really struck home with me. Upon reflection it exactly maps to the evolution that my team has been going through over the past year on our developer tool Splunk AppInspect.
Ken Norton in an effort to help companies understand how to hire product managers wrote a guide: How to Hire a Product Manager I’m here to argue that the person you are looking for might just be a transitioning or former military officer. I have never been a Product Manager, but I have spent the last eight years as an officer in the United States Army, I’ve had the pleasure of working with some amazing peers and the honor of leading, coaching and mentoring some very promising young lieutenants.
Michael Cata’s wrote a smart article discussing the Department of Defense is reacting to changing events with agility. He thinks we have a good start in the Army Operating Concept. In good units the Army already operates as an agile and learning organization. When lead by astute and prudent leaders it can very closely resemble an organization applying the Scrum Methodology.
I’ve helped plan brigade and battalion level operations in my time as a staff officer and company commander. Lots of staff officers and NCOs standing over a map, drawing symbols on acetate, scribbling notes on paper and into emails and documents. Once the drawing is done one or several staff officers walks away from the table and copies all of the graphics onto power point slides and the Command Post of the Future (CPoF). They also produce the all important narrative for the OPORD/FRAGO/WARNO.