You Get Invited When You Add Believable Value

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.

Advice for a brand-spanking new Product Owner

I’ve started a mentee collection.  Not a manatee collection:
My mentees are better looking
I’m mentoring three new Product Owners, collecting them into my posse as I encounter new Product Owners who have no peers/colleagues from whom to learn the ropes.
The rant below was inspired by a real-life plea for help from a newly-minted Product Owner at my company.  Knowing how anxious and overwhelmed I was when I realized what I’d gotten myself into, these are the kinds of “start small, start here, build on your successes” advice I’d give my past self (can we use Skynet’s back-in-time portal yet?):
What could go wrong?
What could go wrong?
  • I’m inclined (especially with new teams, new process, new roles) to start small – get a rhythm, build a few quick wins, get small pieces shipped in short timeframes, even if it’s not technically a “potentially shippable product”
    • The important thing is to start seeing chunks of more valuable engineering work delivered earlier
    • For example, I’m currently getting the team to work on a “research spike” to determine if they can figure out how to add “test our site using IE11” to the test coverage – plus we’re doing the second story (broken up from a larger story) to deliver an Export capability to our project planner (just started with flat file, unformatted CSV as an export deliverable for now – it’s good value to users, and we’ll refine and “gold plate” it later)
    • I’ve also had them working on some of the more ‘valuable’ tech debt over the last few months – cleaning out old database tables, removing dependencies on legacy code and data structures, etc. – all written as “stories” (probably doesn’t fit the dogmatic definition), small bits of work each, that ideally could’ve been done all at once, but are easier to schedule, are establishing a rhythm, and have given them hope that I’m committed to systems hygiene as part of our negotiation between “user value” and “systems integrity”
  • Encourage the team to adopt SCRUM (or whatever flavour of Agile-ish behaviour they’re aiming at) in stages – don’t try to swallow it all at once
    • As a fresh PO, I’d stand up and tell them I don’t expect them to get everything right the first time, and especially not when they’re playing with all these new “process toys”
    • e.g.. Try the “sprint planning” and “retrospective discussion”, and drop everything else, for the first sprint – see how it goes, spend the time discussing “things to do more of and things to do less of” at the end, and ask them whether they’re ready to add “daily stand-ups” or “story point estimation” or “story breakdown” to their process
    • Personally I don’t want process to get in the way of the engineering – I want it to be a net break-even, and if you try to do all the process all at once, there’s no way that they’ll get any effective engineering done that first sprint or two – just too much flailing and failing on friggin terminology, not enough on learning to succeed at the job with incremental improvements along the way)
  • As quickly as possible, focus your efforts on the WHAT and the WHY of every piece of engineering work that the team sets out to do.
    • Any of us that come from engineering will still trip over the HOW too many times to count before we get really good at this, but it’s worth the effort to learn.
    • The most satisfying feeling as a PO is setting the team a challenge you yourself have no idea how they’ll deliver, and watching them struggle, flail and invent something they never knew they could do.
    • Over time, they’ll recognize your trust and confidence in them – in giving them the leeway and slack to take on challenging problems and kick the shit out of them]
    • It’s taken me years to let go of this, and I’m still meddling more than I should, but it’s satisfying to imagine how it’d feel for my ‘product CEO’ to have faith that I’ll do an amazing job figuring out how to make it happen
  • The big focus for you – for as long as you inhabit this crucial role – is to spend as much time in the heads of your users (and unfortunately, stakeholders who aren’t end users) to understand what will be the most valuable thing to deliver to them as soon as possible
  • The trick is “most valuable part of functionality”, not the ideal solution
  • e.g. The users want to be able to import the set of security requirements into their ‘work tracking system’ (Jira, RTC, Rally, Trello, etc).
    • It would be awesome to have it pre-filtered to just what they need, pre-annotated to fit exactly the field structure of each of their tools, and able to be exported back into our system
    • However, the most important first incremental delivery of value before we work out all those problems is “structured list of the names of the tasks, their current status and a link to more info on how to deliver them” – a far cry from the ideal solution, and probably ten steps between here and there
    • I’ll carve out this first step as a story, where the WHY is “I need to track this shit in my native work tracker”, and the WHAT is “the details that are critical to me tracing back to what I need to know to be successful”
    • The rest of that work I’ll represent as notes in a parent Epic, or one or more Stories that may or may not be fleshed out enough for the dev team to tackle (depending on how soon I/we think we might get around to delivering that residual incremental value)
In a future post I’ll introduce the fever-dream “system” I use to calculate priority for each story and Epic, but seriously you’ve got plenty to chew on just getting out of the starter’s gate. We can setup a 1:1 call for whenever in the future you want to review results/commiserate over failures/discuss additional experiments that you’re ready to try.
It’s an adventure – a Very Real experience in both asserting control and letting go of absolute control over the direction of the product. It’s a blast.  If you’re a new Product Owner, welcome to the tribe.

Lonergan’s Iron Triangle of Content

I’ll drop the punchline up front: when designing content management systems, you cannot optimize for all constituents, and those disfavoured will find every interaction laborious and frustrating. Choose your priorities – you cannot favour all three parties at once (at least not at tolerable costs).

I have this conversation at least a couple of times a year at work, and every time I do I end up pulling out this simple diagram and give people the pitch. I am convinced of the truth of this for me in all my years of managing, contributing to and designing content management systems and experiences, but I have no illusions: I’m sure the smarter ones reading this will find faults, flaws and a general lack of intellectual rigour in my thesis.  There are probably better ways of framing the problem space, but as I’m not aware of them, and because everyone I’ve shared this with seems to come away enlightened, it’s here to please and to challenge you.

Mike’s Key Takeaway

Continue reading “Lonergan’s Iron Triangle of Content”

Adventures in Data Modeling: Entity Framework, Model First

sun breaks through cloudsWorking up a data model for a new systems architecture – been spending the last few months working in MS Word, whiteboards and sticky notes.  Feel like we’ve hit diminishing returns by looking at this in the abstract, so I figured I’d hack up an instance in MS SQL to see how much of this thinking stands up to reality.

I tracked down a few online resources to get me back into SQL (it’s been nearly a decade since I dug in deep) – two of note were:

After a day or so messing around with this, my valued conspirator Dale Cox mentioned Entity Framework to me:

And thus was the Bright Light of Truth shone upon my works.  For a guy like me who’s working out the business needs, transforming into Stories, and usually has a lot more to say about UX than about MVVM constructs or SQL queries, this is the perfect level for me to dig into next.  Entity Framework, Model First, using Visual Studio 2013?  I still wouldn’t pay thousands of $$$ for this tool, but here’s one way that it stays relevant for me.

Brain-wringing meetups and my upcoming CHIFOO talk on UX of Comics

I’m getting rather excited about my upcoming talk at CHIFOO on Great Storytelling UX in Modern Comic Books.  Over the next few weeks I’ll be finalizing the content and doing a few dry runs to smooth out the kinks and ensure I’m connecting with the audience at each page that I show during the presentation.  If you have the time and interest in seeing where this is headed, or helping out a guy make sure he’s making best use of the audience’s time, gimme a jangle.


I’ve been out to a few meetups already this year (JavaScript Admirers, CHIFOO, STC) and helped out my poor dog who had a severe glaucoma attack and had to have an eye removed.  She’s bounced back amazingly and doesn’t seem to know that she’s not supposed to be missing an eye, which is a helluva lesson in staying present and adapting to change in this world. (Who knew my dog was a Buddhist?)


Where will you find me in the next couple of weeks?

Further out I’m planning on BarCamp Portland 8 and ProductCamp Portland 2014.  Should be a brain-wringer.