I used to be a product manager at a company that will remain nameless. Here’s how projects worked: First I would put together a project request form that contained a lengthy requirements section. After the engineering team approved this project request, we’d spend a couple of weeks together documenting the business requirements.
This meant daily, hours-long meetings with perhaps a dozen participants, and at the end, the output would inevitably be … essentially my project request form copied and pasted into a new document.
Once 10 or so people signed off on that, we could start the functional-requirements process, which was more or less the business-requirements process, just longer and with a few more bells and whistles. Important engineering work did get done during this phase, but it didn’t have anything to do with the front end, which was the primary responsibility of most of the people involved.
Perhaps six weeks after I’d submitted the project request form, after hundreds of hours expended by people who could have been doing other work, we had a fancier version of the project request form. And that was just the beginning of the project. Imagine what the rest of it was like.
Did we build good software at this company? Yeah, sometimes we did. We rarely built great software. What we did build took a very long time to get to production. And that’s because as an organization, we were far more concerned with process than we were with results. As much as I would have liked to change this process for an individual project, I couldn’t -- because then the project would never get done. Those were the rules.
The philosophy of agile trumps the execution
At MojoTech, we believe strongly in being agile. If you know much about agile, product management, or just software development in general, you surely recognized my former company as painfully stuck in an obsolete waterfall world. But while following agile processes to the letter -- say, Scrum or Kanban -- will surely get you better results than I got, that doesn’t mean you can’t fall into the same trap of blind adherence to a documented process.
I don’t want you to get me wrong here. Processes are important -- critically important. For one thing, everyone on a project needs to be on the same page. For another, these processes generally exist because people have found over time that they’re effective, and nobody wants to reinvent the wheel.
But a process is still a process, no matter how effective it is on average. It’s meant to work in general. Whoever developed it didn’t know about your unique situation. Those people didn’t know you or your team, didn’t know how you work separately and together. And make no mistake: Your situation is unique.
I’ve never been involved in a project that was exactly like another project, nor have I ever been on a team that had exactly the same dynamics as another team. We’re all human, and humans tend to like rules. They make us comfortable. But if you’re ever following rules that seem to be making things more difficult, you need to ask yourself: Is this rule hurting the project? Could we be doing a better job? Those aren’t questions that necessarily come naturally, but they’re important questions nonetheless.
If it’s not working, change it up
To a certain extent, most companies understand this. For example, I’ve never worked at a company that did Scrum quite the same way. Maybe you do backlog refinement at a predictable cadence, maybe you do it whenever the product owner thinks it’s appropriate. Maybe retrospectives have to happen on the last day of a sprint, maybe they don’t happen at all. Maybe you don’t stand up during standups! But typically even companies that mess around with their methodology don’t feel comfortable deviating from whatever proprietary system they’ve put in place, and that’s a mistake.
Does your process demand that you use Jira to document user stories, but the majority of your team is more comfortable with Trello? Then switch to Trello. Maybe your process insists on competitive analysis at the start of a project, but your “competitors” aren’t really competitors at all because they have a very different vision. Then don’t do the competitive analysis! Do you have a mandatory client design review scheduled weekly, but the client doesn’t seem interested and never has anything to contribute? Cancel the review and share your progress some other way.
You can change things up in very little ways, or in very big ones.
Define your own process as a starting point
In the short time I’ve been a product manager at MojoTech, I’ve seen several indications that this is an agency that just gets it.
When I started, I wanted to make sure that I was representing the company to our clients as well as I could, so I asked Nick Kishfy, our CEO, if he had any documentation on product-management processes. As it turns out, we have a guide that lays out a very specific, step-by-step process for engaging with clients and leading a project.
“But feel free to do it however you think is best,” Nick told me.
Once I was finished studying the guide, Nick gave me two short books to read, each laying out the philosophy of a different agency. These two firms, he told me, were both inspirations for how MojoTech does business.
Both books contained invaluable tips and tricks, and both authors were very confident that their way was the right way. But shortly after I started reading the second one, I noticed that it frequently contradicted the first. The first book’s philosophy, if I can boil down an entire book to one line, was: “Don’t worry about the details, just get it done and figure out the details later.” The second book’s philosophy was: “Worry about the details, then get it done.” These ideologies were so diametrically opposed that I had to ask Nick which one was right.
“Err on the side of the second book,” he said. “But you don’t have to follow it to the letter.” And of course I didn’t have to follow it to the letter -- after all, he had given me the first book, too!
That’s exactly how you want to handle it. Yes, lay out a very specific game plan -- if you don’t, you’ll end up in the Wild West, with everyone on the team confused about how they’re supposed to be working and ultimately very little getting done. But at the same time, make sure everybody knows that if a particular step in the process isn’t going to work for a project, they should feel free to discuss that and change it.
Product managers, product owners, and scrum masters should be able to define new standards from the very beginning of a project -- or, if it’s not going to confuse matters and interfere with the project’s progress, they can change it up in midstream. I’m looking at this from a product manager’s perspective, but the same goes for technical leads or anyone else in the organization.
Especially if you work for a large company with a lot of legacy processes -- but even if you work for a smaller, more nimble company -- it’s easy to forget why we’re all here. Our job, all of us, is to release great digital products. No more, no less. Anything else is just a means to an end.