Category: Salt Mines

Occupied Neurons, early May 2016

Published on by paranoidmikeLeave a comment

The continuing story of the intriguing ideas and happenings that I can’t shake off…

Pigsinspace222

(Have you ever seen an episode of Pigs In Space?  If not, go sample one now, and you’ll get my droll reference)

Infinite Scrolling, Pagination or “Load More” Buttons? Usability Findings in eCommerce

https://www.smashingmagazine.com/2016/03/pagination-infinite-scrolling-load-more-buttons/

Summary (and something I plan to bias towards in future designs, under similar conditions): The “Load More” design pattern is the most well-received by users and creates a minimum of friction while still enabling access to the page footer.

How Spotify’s Poor API Hygiene Broke a Bunch of Hardware and Software

http://www.programmableweb.com/news/how-spotifys-poor-api-hygiene-broke-bunch-hardware-and-software/analysis/2016/02/23

This is a pretty epic rant on the fallout for independent Spotify developers from a haphazard approach to managing the APIs offered over the years by this consumer entertainment service. Having worked on the other side of these kinds of decisions, I can well imagine how this came to be: thin staffing levels keeping from putting adequate attention on developer communications and engineering maintenance, plus distracted attention by PMs (or possibly even frequent PM turnover) such that late in the game, no one even remembers lets alone still believes in the original value prop behind the original APIs.

It doesn’t excuse the broken promises behind the APIs, and especially not the lack of communication in obvious channels when changes were made (eliminated), but I’ve been in such positions as a Product guy and found myself making decisions that feel just as compromised – trading off one disappointment for a better-mitigated disappointment elsewhere. It happens, especially when the product being extended through those APIs has a pretty low profit margin, and when the staff devoted to managing those concerns are terribly compromised (higher priorities and all).

Theory of Constraints

https://en.m.wikipedia.org/wiki/Theory_of_constraints

At the Intel-sponsored Accelerate Results gathering, a few themes/durable concepts kept coming up (and have come up in this community repeatedly over the years). One is the Theory of Constraints, which seems popular among all systems thinkers, even in big software design (at least in concept if not in execution).

I firmly believe we have a duty to consider outside perspectives on our industry, even when they appear to have no direct applicability – myopia, tools bias and fad-driven design/execution are the restraints I make deliberate effort to resist in my own practices.

Standing on the Shoulders of Giants

http://www.business-improvement.eu/toc/Goldratt_Standing_On_The_Shoulders_Of_Giants.php

Eliyahu Goldratt is a huge influence on the thought leaders at the Accelerate Results conference, and many made reference to his seminal essay that seems to have kicked off this whole revolution. Worth a skim, even if it’s only to be able to nod thoughtfully when others keep talking about this.

Everyday Internet Users Can Stand Up for Encryption — Here’s How

https://blog.mozilla.org/blog/2016/03/30/everyday-internet-users-can-stand-up-for-encryption-heres-how/
I worked with Mark Surman a long time ago back in Toronto for a non-profit Internet Service Provider. It’s more than a little amazing to me to see how our paths have diverged and yet how he’s speaking about issues today that are very near and dear to my heart.

Occupied Neurons, April 2016

Published on by paranoidmikeLeave a comment

https://medium.com/@sproutworx/six-templates-for-aspiring-product-managers-a568d3115cfe#.swkk52f58
So many Product Managers are making it up as they go along – generating whatever kinds of artifacts will get them past the next checkpoint and keep all the spinning plates from veering off into ether. This is the first time in a long time I’ve seen someone propose some viable, useable and not totally generic tools for capturing their PM thinking. Well worth a look.

https://medium.com/swlh/mvpm-minimum-viable-product-manager-e1aeb8dd421
The “BUT” model for Product Management is a hot topic, and there’s a number of folks taking a kick at deciphering it in their context. I’ve got a spin on it that I’ll write about soon, but this is a great take on the model too.

https://schloss.quora.com/Design-doesnt-deserve-a-seat-at-the-table
Captures all my feelings about the complaint from Designers (and Security reviewers, and all others in the “product quality” disciplines) that they get left out of discussions they *should* be part of. My own rant on the subject doesn’t do this subject justice, but I’m convinced that we *earn* our right to a seat by helping steer, working through the messy quagmire that is real software delivery (not just throwing pixel-perfect portfolio fodder over the wall).

http://www.eventbrite.com/e/resilience-and-the-future-of-work-responsiveorg-un-conference-tickets-24045089510
An unconference to expand awareness of a movement among leading thinkers on how to organize work in the 21st century. Looks fascinating – unconference format is dense and high-learning, the subject is still pretty fresh and new (despite the myriad of books building up to this over the last decade), and the energy in the Portland community is bursting.

Meetups where you’ll find Mike’s hat, Spring 2016 edition

Published on by paranoidmikeLeave a comment

Occasionally I’ll tell people I meet about all the meetups I have so much fun at.

Or rather, I’ll try to enumerate them all, and fail each and every time.

Primarily because there’s so many meetups I like to check in on.

So occasionally I’ll enumerate them like this, so that my friends have a valiant hope of crossing paths with me before the amazing event has passed.

Meetups I’m slavishly devoted to

Meetups I’ll attend anytime they’re alive

Meetups I sample like caviar – occasionally and cautiously

Recent additions that may soon pass the test of my time

 

Pruning features via intelligent, comprehensive instrumentation

Published on by paranoidmikeLeave a comment

Today’s adventures in the LinkedIn Product Management group gave us this article:
http://product.hubspot.com/blog/the-5-whys-of-feature-bloat

The critical statement (i.e. the most/only actionable information) in the article is this:

Decide a “minimum bar of usage/value” that every feature must pass in order for it to remain a feature. If a new feature doesn’t hit that bar in some set period of time, prune it.

I’d love to hear from folks who are able to prove with data that a feature is not getting the level of usage that we need to justify its continued existence.  AFAIK, whether it be a desktop, mobile or web/cloud app, instrumenting all the things so that we have visibility into the usage of every potentially-killable feature is a non-trivial (and sometimes impractical) investment in itself.

I’m not even arguing for getting that work prioritized enough to put it in up front – that’s just something that if it’s technically feasible, we should *all* do to turn us from cavemen wondering what the stars mean to explorers actually measuring and testing hypotheses about our universe.

I’m specifically inquiring how it’s actually *done* in our typical settings.  I know from having worked at New Relic what’s feasible and what are the limits of doing this in web/cloud and mobile settings, and it’s definitely a non-trivial exercise to instrument *all* the things (especially when we’re talking about UI features like buttons, configuration settings and other directly-interactive controls).  It’s far harder in a desktop setting (does anyone still have a “desktop environment”?  Maybe it’s just my years of working at Microsoft talking…).

And I can see how hard it is to not only *instrument* the settings but gather the data and catalogue the resulting data in a way that characterizes both (a) the actual feature that was used and, even better, (b) the intended result the user was trying to achieve [i.e. not just the what or how but the *why*].

Developers think one way about naming the internals of their applications – MVC patterns, stackoverflow examples, vendor cultures – and end users (and likely/often, we product managers) think another way.  Intuitive alignment is great, but hardly likely and usually not there.  For example, something as simple as a “lookup” or “query” function (from the engineering PoV) is likely thought of as a “search” function by the users.  I’ve seen far more divergent, enough to assume I won’t follow if I’m just staring at the route/controller names.

If I’m staring at the auto-instrumented names of an APM vendor’s view into my application, I’m likely looking at the lightly-decorated functions/classes/methods as named by the engineers – in my experience, these are terribly cryptic to a non-engineer.  And for all of our custom code that wove the libraries together, I’m almost certainly going to have to have the engineers add in custom tracers to annotate all the really cool, non-out-of-the-box features we added to the application.  Those custom tracers, unless you’ve got an IA (information architecture) nut on the team to get involved in the naming, will almost certainly look like a foreign language.

Does that make it easy for me to find the traces of usage by the end users of a specific feature (e.g. an advanced filtering textbox in my search function)?  Nope, not often, but it’s sure a start.

So what do you do about this, to make it less messy down the road when you’re dying to know if anyone’s actually using those advanced filtering features?

  1. Start now with the instrumentation and the naming.  Add the instrumentation as a new set of acceptance criteria to your user stories/requirements/tickets.  If the app internals have been named in a way that you understand at a glance, awesome – encourage more of the same from the engineers, and codify those approaches into  a naming guideline if possible.  Then if you’re really lucky, just derive the named instrumentation from the beautiful code.
  2. If not, start the work of adding the mapped names in your custom instrumentation now – i.e. if they called it “query”, make sure that the custom instrumentation names it “search”.
  3. Next up, adding this instrumentation for all your existing features.  Here, you have some interesting decisions:
    • Do you instrument the most popular and baseline features? (If so, why?  What will you do with that data?)
    • Do you instrument the features that are about to be canned? (If so, will this be there to help you understand which of your early adopter customers are still using the features – and do you believe that segment of your market is predictive of the usage by the other segments?)
    • Or do you just pick on the lesser-known features?  THESE ARE THE ONES I’D RECOMMEND for the most benefit for the invested energy – the work to add and continue to support this instrumentation is the most likely to be actionable at a later date – assuming you’ve got the energy to invest in that tension-filled EOL plan (as the above article beautifully illustrates).
  4. Finally, all of this labour should have convinced you to be a little more judicious in how many of these dubious features you’re going to add to your product.

Enhancing your ability to correct for these mistakes later is great; factoring in the extra cost up front, and helping justify why you’re not doing it now is even better.

And all that said?  Don’t get too hung up on the word “mistakes”.  We’re learning, we’re moving forward, and some of us are learning that Failure Is An Option.  But mostly, we’re living life the only way it’s able to be lived.

success

Purity of Product, Sales or Code – are ALL wrong

Published on by paranoidmikeLeave a comment

I caught this echo-chamber discussion on the LinkedIn Product Management channel:

https://www.linkedin.com/comm/groups/42629/42629-6103296611813781509

Somehow I thought I’d mention a thing or two and then bail, but the more I wrote the more strongly I felt how misguided the “keep your product vision pure” message was. Here’s what I wrote, think of it what you will:

Purity of the product is one ideal; never losing another “key” sale is another such ideal. Making every user happy and productive with your product is a third such, and never shipping imperfect code is yet another.

None of these ideals can be achieved in isolation for very long *and* maintain a successful business. Sometimes we have to flex on one of these ideals to help the rest of the organization improve their position on another.

If I put my foot down and refused to engage with any of my key customers’ feature requests, any responsible sales exec would have my head…examined.

If I gave into every customer want, no product leader (engineering, marketing or product management) would have any faith in my vision of the product.

If I constantly let the engineers gold-plate the code and drive out all tech debt, we’d be so far behind the market we’d never get around to acquiring new customers.

Rallying around the banner of “never let Sales disrupt the purity of my product’s vision@ sounds just as naive as “never ship an insecure product” and “always involve your Designers up front and throughout the development process” (both of which I’ve observed firsthand in those respective domains).

Never forget that every signal from the market can be that incredible insight that *causes* you the change your product strategy, and Sales are often your eyes and ears gathering input from customers that you yourself weren’t there to acquire.

Best advice? If it’s a significant sales opportunity/downgrade, and you haven’t spoken with that customer before, it’s worth considering taking a half-hour out of your schedule to qualify the sales opportunity *and* the feature request yourself – if only to increase the strength of the signal and decrease the risk of making the wrong call.

I personally don’t do enough of this, but when I do it gives me irreplaceable opportunities to learn from customers who aren’t there to feed me what they think I should hear (i.e. the standing “customer council”) and let me pivot the conversation to find out what else they really need (i.e. other items in considering) that Sales didn’t take the time to ask about.

New job at New Relic: First Month Report

Published on by paranoidmikeLeave a comment

An incredible place, rewarding experiences, emotionally engaged people.

Week one: feeling incredibly welcome, people are buzzing by saying “hi” but dropping no turds in my lap

Week two: I’m starting to get to understand the scope of my job and it terrifies me; tigers are lurking in the shadowy forest, and I’m hearing some occasional growls

Week three: I’ve slain a small house cat and feel like a warrior born; scouting parties are starting to make contact, and I’m getting involved in a real (but small) skirmishes with that beast they call “work”

There’s three levels of tired that come with an amazing new job:

  1. Tired when I get home. “I might turn in at a reasonable bedtime, honey.”
  2. Bone tired as I drag myself down the street, hoping I I don’t get mistake for a drunk before I get home.
  3. Drop like a sack of rocks when I cross the threshold. “I’m sorry I drooled on you while using you as a pillow, Mr. Fellow Bus Passenger.”

I am so glad I’m not driving home after work these days – “reckless” and “menacing” would be likely adjectives among the charges.

Highlights include:

  • Hardest mindfulness lesson: “we have two ears and one mouth, so we should listen first and then speak” – I am fighting to curb every ego instinct I have to stop trying to sound smart (show off as if I already understand all this new shit) and ask questions or just look like I don’t know what everyone’s talking about
  • Met a dude who spent six months working between Stockholm Sweden and Hillsboro Oregon. (We made many jokes drawing increasingly-strained comparisons between the two sexy locales)
  • Favourite hair colour I’ve seen: burgundy/orange/yellow stripes (like a funhouse Neapolitan ice cream)
  • Estimated number of people who recognized me by my hat: 5 by Tuesday
  • How welcome I felt by the end of day one: 10/10 (would do it over again)
  • How overwhelmed I felt by the end of week two: 12/10 (would crush my brain over again)
  • Best Google Mail hack: http://klinger.io/post/71640845938/dont-drown-in-email-how-to-use-gmail-more
  • “6months” – the amount of time every SINGLE person says it’ll take for me to be a net contributor to the business
  • New phrases: “icebergs vs. ice cubes” (are problems big, or do they just start out that way because everything’s so loud at the start), “N+1 query”
  • Never laughed as much at work – spontaneously – at least not sober. This is a very entertaining group of folks (or they’re just as warped as me). Friday’s highlight – “Anyone interested in a quiche run to Lauretta Jeans? I’m feeling like elevensies today.”
  • Bus asymmetry: getting on the 14 (Hawthorne) anytime between 7:30-8:30, sit with lots of normal, quiet, keep-to-themselves people. Getting on the 4 (Division) at work towards home anytime between 4:30-6:30, (and couldn’t think of a good joke to wrap up this thought)
  • Best spontaneous phrase I came up with to describe my mental state by week 3: the project plan I drafted hasn’t made me feel competent, but it “bounded my insecurities”
  • Perspective I heard I love: Intuit obsesses on our customer problems, not on what we’re building
  • “Discovering not declaring” how core values were generated
  • “Bring out the best in each other” – not a regulated nation-state

On the scale of behaviours of people with whom I’ve had to work in my career, the worst of them I’ve encountered at New Relic are pretty mild, and the best of them are bend-over-backwards nice, helpful and fun to be around.

Anticipation

Published on by paranoidmikeLeave a comment

Contemplating the question of whether I’m ready for my new job as an annointed (annoying? the words sound so similar…) Product Manager at New Relic.

iu-2

Excited, yes! This is going to be a learning opportunity without compare, and tons of opportunity to get to know a whole new set of customers.  The amount of stuff I don’t know is huge – I know a lot of stuff on which I’ll build, and I’m a super-sponge for the customer needs, the way their tech works, and what’s really important to everyone – and there’s plenty of opportunity to live that dream.

Nervous? Hells yeah. Those customers could be very demanding; the engineers might find me wanting; the technology is terribly complex and I worry if there are things I’ll just never get.  Worst case, they’ll encounter me as one of “those people” – the folks who don’t understand the technology, are talking out their ass, and end up misrepresenting the way it really works or how long it could really take to deliver a new feature.iu-3

Ready to start working?  Um.  YES.  I’ve been getting more and more anxious about all the what-ifs, the ways I might embarrass myself and how many ways I want to help out and make good stuff happen.  I thought the time off between jobs would be helpful to get my mind at ease and clear of the old world; clear was easy, but ‘at ease’ was apparently not in my playbook.

See you on the other side!iu

Leaving Intel on a (commuter transit vehicle?) – New Relic here I come!

Published on by paranoidmike1 Comment

Good news. Hell, great news!!  I’ve accepted a role as Product Manager at New Relic (a very cool, local Portland-based software company). I’ll be joining them later in July – wild adventures await!

So with that simple admission comes a little Story Time: you know me, and you know I’ve grown into a well-oiled Product Owner and Interaction Designer in my work at Intel (for basically the same organization for my eight years there).  

Working for them allowed me to grow into these skills while delivering a suite of business applications, a Security Conference website and as little paperwork as I could get away with.  

[None of those fully-stocked portfolios of art pieces for me – I stopped trying to “build my portfolio” when I realized it was a textbook example of the Waste that gets in the way of thoroughly agile development.]

Using those skills, I birthed the core application out of conversations I had with team members in 2008, and shepherded it through:

  • its underground “you shouldn’t spend any time on this Mike” phase
  • a series of dev teams (man, when I was first delegated “half an engineer”, what a momentous achievement that was!)
  • many competing ‘visions’ of what it should be when it grew up, and
  • over 100 sprints of delivery – short, long, successful, abject failure, research, tech debt, “spike” (aka “we have no idea what we’re doing”), breakneck, misdirected and surprising

Recently I took on an exciting and challenging volunteer assignment with an IT team who are responsible for internal collaboration tools.  Which was both a rewarding and fast-moving learning experience – it’s incredible how much planning goes on when you have a 4:1 ratio of non-doers to doers, and it’s amazing to see how much good dev work actually happens despite that.

A little while later, a friend recommended me to a hiring manager at New Relic, who reached out for a coffee to talk about a ridiculously challenging role they’ve designed to assist their Agents teams. That conversation continued through three rounds of interviews (and a heavy-duty homework assignment!) and blew my mind by manifesting into an offer I patently couldn’t refuse.

This new PM role is both incredibly suited to my talents and brings a range of new challenges for me to tackle – I’ll be contributing to product direction for six teams in a fast-growing, revenue-focused organization with a heavy engineering bent and a lot of new customers and technologies to learn. I couldn’t be more excited about this.

So hey, if you happen to be looking for new features in the New Relic product stack, drop me a line come end of July and I’ll see if I can’t connect you to the right players (it might even be me!).  I will use my newfound powers with utmost gravity…
Spidey

You Get Invited When You Add Believable Value

Published on by paranoidmike1 Comment
I’m constantly amazed and amused at this kind of “but *I* deserve to be invited too” thinking:
All too often folks don’t want to bring everyone in on Day 1.
And that’s the real problem.
They don’t want to relinquish the (illusion of) control. They want the freedom to make many of the decisions without participating in this crucial collaborative work. Well, guess what? That’s a very costly move: The later everyone is brought in the greater the overall project risk.
In my career, I’ve heard this from the Operations folks, the Support team, the Security high priests, and most recently from the UX zealots.
This usually takes the form of “but if only they’d included us too in the conversation at the beginning, we wouldn’t be in this mess” fantasy.  The longer I watch these folks argue from the sidelines [and one of the things I used to do], the less sympathy I feel.
Telling us on the development & delivery side of the organization that we need to include you too feels a little like telling a kid they have to watch all the good movies with their parents in the room.  I’m sorry, what exactly about that sounds like an incentive?
“Oh, well if you found that security flaw in architecture instead of during test, it would’ve been orders of magnitude cheaper.”  As if it’s a pure win-win scenario – and not, as reality suggests from talking to the folks actually doing the real work, that rather than *prevent* every statistical possibility, often times we’d rather get the product out in front of people and find out which things *actually* bit them/us on the butt, and only spend time fixing *those* things.  Get product out there capturing revenue months earlier, plus reduce your investment on the long tail of an infinite number of possible issues that would cost schedule and profits to fix up front (and turn out to be non-issues)?  Yeah, you don’t need an MBA to make that kind of call.
[Not to mention, “fixing something in architecture is cheaper” assumes (1) that the architecture is communicated, interpreted and implemented carefully and successfully, (2) that new bugs aren’t introduced at every translation layer because the architects abandon their responsibility to follow-through, and (3) that they anticipated and addressed every implementation issue.]
“But if you just invited the UX designers/researchers before starting to talk about product features and ideas, you’ll have a much wider palette of well-designed ideas to work from.”  Yes, that’s potentially true – if your designers have a clear idea what the target users need – or if the researchers can turn around actionable findings in a short timeframe – or your UX bigots don’t throw cold water on every speculative idea and colour the conversation with “how crappy everyone but me is”.  That dude is real fun at parties.
We love working with that guy
Are you one of these people I’m picking on?  Are you sufficiently pissed off yet?  OK, good – then we’re getting close to a defensive wound we’re all still harbouring.  Which is the right time to clarify: I absolutely appreciate working with folks who are aligned to our business priorities, and work to get us actionable results in a timely manner that are relevant to the business problem we’re facing.  I’ve spent decades now working with security and usability geeks, and some I’ve found to be extremely helpful.  Some I’ve found less so.  Guess which ones I’ve heard complain like this?
Here’s the pitch from a Product Manager to everyone who’s vying to get a seat at the table: I don’t have enough room at the table to entertain everyone’s ego.  You ever try to drive an effective decision-making body when the room (or conference bridge) is stuffed so bad, it looks like a clown car?
It's a fun ride until you can't breathe
It’s a fun ride until you can’t breathe
Those who I invite to the table are effective collaborators.  If you have a concern, make sure it’s the most important thing on your plate, make sure it’s something I can understand, and make damn sure it’s something that’s going to have an impact on our business results.  Every time you spend your precious ante on “but what if…” and not “here’s a problem and here are all the possible/feasible/useful solutions, depending on your priorities”, your invitation to the next conversation fades like Marty McFly’s family in that photo.
McFly-Erasedfromexistance

Conferences and unconferences – I’ll go to the latter over the former every time

Published on by paranoidmikeLeave a comment

Best conferences I go to have no prepared agenda, no “luminaries” aggrandizing themselves, lots of fascinating up to the minute topics and copious discussion in session. “Papers” written in advance is the best way to stifle all that rich interaction, because it’s a sieve to filter out all those who haven’t yet attained expert status – and I rarely learn as much from experts, since they are usually quoting from their own tired catchphrases rather than original thought in response to others’ earnest inquiry.

Give me the interaction – that’s where I learn best – over the lecture. If I can throw in an inspired idea (or sometimes, a bit of snark) and hear a legitimate response to that, it far exceeds my trying to silently (or long after the monologue has completed, from an over-lit and terribly conspicuous microphone) parse out a heavily compacted or cryptic thought pattern. 

Give me intimacy, not hollow echoey halls filled with row upon row of anonymizing and silencing seats. 

Give me half-baked theories or simply questions to get the ball rolling, rather than twee or horribly over-thought concepts that are important only to the speaker (because they actualize the speaker’s self-centredism rather than actually enlighten the audience (and maybe even the facilitator).

Give me an unconference, not a conference. Scale is nearly impossible in the former, and often seems the point of the latter. Bragging rights is not how many attendees, but how many smiles and new connections.