September marks my first year in product. How I got here isn’t exactly a straight line though.
Did I study IT or a similar technical degree in college? Nope.
Did I receive a MBA fast tracking my career? Go fish.
Did I ever go through a formal training, workshop or certification before I officially started in product? Strike three.
When I started in product I had unanswered questions (some of which, still are unanswered) about what this career would entail. I knew what my “job” and “responsibilities” were bound to be, but what was actually “expected” from my day-to-day could potentially differ.
Thus, here are a collection of my learnings (though not all!) that I wish I knew before I entered product, as well as some experiences from what this first year brought me.
*Note, the term(s) product and product management are used interchangeably throughout this article.
Your days don’t go as planned
And that’s okay. You learn to adapt and expect that. After all, isn’t that what agile’s all about?
Realistically, most of your days are in meetings or putting out fires.
I’ve walked into work before, had a full day of meetings and none of it actually happened. Call me crazy, but the fun part of working in product is walking into a fire and having to find some way put it out.
For one of our latest feature releases, we were in the final month and final stages of development. One day we discovered a major showstopper that ended up delaying our release. What fun to walk into. You adapt, you go with the flow. As much as you try to forecast and plan things out, a major reality is that you react to a lot of moving parts.
Failure is a HUGE part of product management
If you aren’t able to handle failure and/or only expect success, you’re going to struggle in product management.
One thing most in product would agree with is that not every idea you’ll have will be good, let alone successful for that matter. Accept that now.
If you throw a bunch of ideas at a board, maybe one or a few will stick, if at all.
You learn through failure, with growth and improvement stemming from this. If you’re really going to innovate and create, you’re going to have throw some ideas out there.
Some of my professional failures have come from assuming something is done the right way or accounts for all details. This has burned me before, so now I check everything to the nth degree. Whether it’s a vendor, SaaS product or a major migration, it’s better to measure twice and cut once. Nothing good ever comes from assumptions — do your due diligence and do it right.
Gather user insights as early, often and frequently as you can
“We have enough user insights, we don’t need any more!”, said no one ever.
There’s no such thing as too much user data. More often than not, bad product decisions are results of poor research and user feedback. I’m lucky our department focuses on gaining user feedback as often as we can and in a variety of formats. Some of my colleagues not only excel in putting our users first, but they are strong in routinely interacting with users directly. Garner all of the data you can and absorb it up to help drive thoughts for your new features.
In my last role, I was a hybrid digital marketing + digital project manager. I never once interacted with our users to understand if they liked using features on our varying digital touchpoints (website, online ordering, in-store, email, loyalty & more).
So I blindly built and developed futures without any validation or confirmation. That was a major mistake and a huge learning I’m taking with me for the rest of my career.
If you want to build a product right + successfully, focus on one not two
After a few weeks of starting, I ended up gaining an additional product. I felt overwhelmed as I adapted and navigated having to split focuses between two products.
I was happy and I welcomed the opportunity to take on more, but I was still very green in the product role. I struggled with splitting my time, attention and focus on two products, with two sets of ceremonies (double the meetings!), different teams, different stakeholders and more.
One day I approached our agile coach to see if he had any recommendations or advice. He told me:
“If you want to build a good product, you can focus on two products. But if you want to build a really great product, like a really great one, you can only focus on one.”
Everything then made sense. You aren’t giving your best if you’re only giving 50% of it. If you want to really build a great product, you have to be 100% focused.
Agile and agile principles vary and evolve with each team
Agile can be tough in some instances for those in non-development.
The team I work with is a mix of engineers, architects, business analysts, designers and marketing. As you can imagine, with any role, there are some stories you can size effectively and know what you can realistically pull in/finish within a sprint.
For other stories, I’ve struggled with framing the story, acceptance criteria and sizing knowing it would need to carry over into the next sprint. Some of the contributing factors include: outside dependencies on other teams and areas (feedback, availability, etc.), work changing because of those dependencies, and process-based work.
It’s hard to say, “we’re only going to partially design ____” or “we’re only going to do some of this work” because the majority of the work is larger than a regular 2-/3-week sprint cadence. We do our best to size and slim down the story to only be what will be accomplished, but it still can be challenging.
Non-agile areas can struggle with understanding agile.
No matter how much outside business areas (internal, external, what have you) have been involved with agile in the past and/or educated, they’ll struggle with understanding it until they are fully operating in an agile fashion. Deadlines will waver based upon availability/requests. No matter how much you have confirmed beforehand, unexpected or last minute requirements will arise and impact MVP. Trying to explain to new employees in other business areas about agile ceremonies and why we work the way we do will continue to be a challenge. That’s okay, but they all have an impact.
Overall, agile varies based upon your team buildout and evolves with your team’s continued growth (gotta love those retros!).
This is just the beginning for me…I’m excited for what the future holds — especially building and creating this technological future as it unfolds right before our eyes. I look forward to revisiting this piece years down the road as my career progresses, while continuing to add new learnings.
What am I missing? Is there anything you’ve experienced or seen in your career that would be of benefit for me to know?
*Opinions are my own and not the views/reflections of any companies I currently or have previously worked for.