Well December certainly didn’t start the way I’d hoped.
Towards the end of my trip the week of Thanksgiving, I caught a wicked cold, that while it didn’t knock me completely out, it did limit the amount of time I could be truly productive.
So for these past two weeks I had to make some tough decisions about where to spend the limited time where I was able to be productive.
That meant committed client work took precedence and InsideProduct had to take a back seat.
I could’ve written something, but it’s hard saying what the result would’ve been. It may have been… entertaining, but there’s probably a good chance it wouldn’t have been too helpful.
I’m also going to resist the urge to turn this into some sort of contrived lesson on decision making. Basically I could only do so much, so I chose client work first.
What that means for the rest of 2024
Thankfully, I’m on the mend now.
So as I look at the rest of 2024, I realized with the holidays and a couple of big writing projects, the best thing for the quality of InsideProduct is to take the rest of the year off and come back ready go at the start of 2025.
My plans for 2025
Before it gets a little quiet here for the next couple of weeks, I wanted to let you know a bit more about my plans for 2025
My intent for InsideProduct has always been to cover a specific context that I don’t think gets enough attention. I’ve referred to it as internal products and working with organizations that build software for their own use.
Think all of those teams doing custom software development in financial services, insurance, retail, healthcare manufacturing and other industries that don’t sell software, but rely on it to run their businesses.
This niche has grown (although some people may not realize they’re in it) as more organizations underwent digital transformations and started looking to the product model for some tips to be successful.
There is an abundance of resources about product management, but very few talk about the explicit context they’re talking about. And in most cases the context they assume is a tech firm, be it a startup or one of the FAANG organizations.
The problem with this is those resources often make statements that while true in the context they’re writing from don’t necessarily apply in an org building software for it’s own use. People not working at a tech company read those articles and immediately think “that won’t work here” or they try out the prescriptions and run into all kinds of challenges.
In many cases, an explicit acknowledgement of the context in which the advice applies would do wonders to making it more useful.
My intent for InsideProduct is to provide that type of context specific help.
The people I’m primarily targeting for this type of context specific help are folks in business analyst and product owner roles. These folks are more often than not the ones that are either doing work that could be described as product management, even if they’re working on something used inside their organization.
These roles are often the target of quite a bit of unfair abuse, so it’s my hope to equip folks in these roles with these skills they need to have successful careers and to prove all the haters wrong.
So starting in January, look for a series of articles that explains this in a lot more detail.
In the meantime, Happy Holidays!
Thanks for reading
Thanks again for reading InsideProduct.
If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.
Talk to you next time,
Kent