All too often folks don’t want to bring everyone in on Day 1.
- 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)
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
Working 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:
- How to Install SQL Server 2012 Management Studio Express on Win7 and Create a local SQL database
- DBA community on StackExchange
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.
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.
Where will you find me in the next couple of weeks?
- IxDA “Dan Klyn + Mozilla’s new office + Food + Drinks = Proficuous“
- PDX-UX “Lean UX & Prototype Testing with Julie (JB) Booth“
- CHIFOO “Persona Stories: Weaving Together Qual and Quant for a Richer Picture” (meetup beforehand for CHIFOOd and a drink!)
- PDX Quantified Self “Show and Tell“
Further out I’m planning on BarCamp Portland 8 and ProductCamp Portland 2014. Should be a brain-wringer.