I Love Clicking
I love it when things just “click” in my head and I just “get” them. I’ve found that this is how I’ve learned / progressed the most. All of a sudden, after breathing / eating / living a single thing for long enough, all of the factors that I’ve been questioning just come together and get really clear.
There is plenty for me to learn, and much of it will come through talking to those that may have already lived through similar experiences, as well as trial-and-error. I’m good with that, because I feel like I can learn from, and recover quickly, when in error.
On the other hand, I also feel that even though I don’t have a bajillion years of experience, my instinct guides me a lot and it is awesome when these “clicks” do happen. It doesn’t happen frequently, and to be honest, I’m glad it doesn’t. But when it does, I initially find myself thinking, “this can’t be right–oh, wait — yes it is!” Coolness.
Ok, crazy rant done with.
Slow Internet Sucks
I am so used to having faster Internet access wherever I am - office, home, a friend’s house - it doesn’t seem to matter. BUT, when that access becomes slow (like, 28 baud slow), I’m forced to hate the Internet.
My mind seems trained to operate as fast as a broadband Internet connection. I want to do 5-10 things at once, have multiple tabs going in FireFox, yet can’t seem to get anything moving along quickly. I’ve checked and re-checked each Airport Express in the house, and the only thing that I can think of is our crappy Internet provider.
However, tomorrow, that will stop. I’m currently, albeit slowly, looking for another provider. Hopefully either cable to DSL and no more of this “T1 shared throughout the entire building” crap, by some company that has headquarters in Arizona. No, no. I want to be able to get a tech support person on the phone during Pacific time.
Blech. Broadband speeds have tainted me. On another note, I’m still loving Windows Live Writer.
Windows Live Writer
This product is pretty friggin cool.
It looks slick, it feels slick, and wouldn’t you know, I’m like one of the last people to actually realize it freakin’ exists.
Blame it on working through .NET wrappers and baselining products.
Yes, it only runs on Windows, which is going just fine on my ole Thinkpad, thank you very much.
I am pleasantly surprised that it does support blogs OTHER than Live Spaces, which rocks.
Outstanding PM Blog
I want to point out the blog Grillin’ in the Storm.
Subscribe to this, visit it daily, etc… The posts on here are so freakin’ amazing — I’ve learned more from all of the posts here than I have from any book I’ve read on Product Management.
Why XPM Is Key
What the hell is XPM? extreme Product Management. Cheesy buzz term? Oooh, yeah. Important? Yes. Why? Let’s discuss.
I’m not a big company guy, which I think I’ve established over the course of several blog posts. Small companies are typically tight on many things — some which are:
- Time
- Money
- Resources
So, what are they NOT tight on?
- Wanting success
- Feature & innovation ideas
- Product ideas
- The need for speed
So far, cool, right? Well, not really. Hows does this pan out in the end? Folks can get real ansy in a small org when things take too long. Small companies can move faster than IBM or GE, right? Yes. But remember, moving fast is only one piece — stopping / turning on a dime is something else.
Waterfall projects are a pain in the ass, IMHO. Why? Well, because typically, at least in my universe, no one can tell the future. Now, I could be on my own here, but I’ve never been able to predict (with some semblence of accuracy) what is going to happen 6-8 months from now. So, where does this leave PM’s? With a need to be extreme. But, I hate that term — I prefer agile.
Traditionally, you give developers requirements 1 time, they implement, and that’s it. If the requirements are wrong, then the PM gets slapped around / chained up / whipped / etc… Why is it that someone who is essentially tasked with telling the future gets in trouble when they are wrong? It’s a simple fact — requirements will never be right in all cases. Using an agile PM concept can solve this by allowing a PM to put requirements in front of a developer, and iterate on them (within reason / bounds) to ensure that the end result will pass BAT, and it’s what was envisioned.
Of course, I’m a silly kid without any grey hair, so don’t trust me — you can trust Steve Johnson. You can trust Roger Cauvin. You can trust all those PM’s with 15-20 years experience that I listen and adhere to and learn from daily, to make sure I can at least voice on this blog what I feel is a successful way to do things.
Why limit the success of a product by being able to tell the future? I do agree, that with something that’s agile, boundaries have to be established. Otherwise, you run the risk of never actually shipping anything due to perfectionists. However, factoring in the need to iterate on the foundation of what is actually being developed, at least from where I’m standing, is a great way to ensure things are more successful than trying to drive everyone into a dense white fog without being tethered together at the wrists. Reset, re-adjust, re-balance, whatever — set the milestones, work towards them, and have everyone on board with the idea that: yes, requirements are going to change to make sure what we ship is killer.
Now, I have used the term “concept” in this post more than once. I also believe that shoving “agile methodologies” down everyone’s throat is not the way to go. However, making sure that market knowledge / requirements are not just pipe dreams (and they all to often are), is critical. Don’t just say you listen to customers — actually listen to customers and do your homework.
And for me, it all ties into not relying on someone being good / accurate at pulling out their crytsal ball. Don’t set dates for things to be delivered if the requirements aren’t understood, and developers don’t agree. After all, they need to know what it is they are committing to before committing to it. Saying everyone is going to go really fast and then leaving it to chance and “good solid hard work and long hours”, is not common sense. I’m not advocating process-heavy, goliath type stuff. I’m advocating concepts & understandings within an organization that can be used during execution to help ship cool / great products.
I’m advocating agility.
