The “Tim” story

I had the chance to work on a discovery sprint recently. During this two-week sprint, I revisited a bunch of agile delivery fundamentals in a way I haven’t in a long time. The project was suffering from some of the great, classic mistakes of software delivery we all know and love such as working in silos, internal politics, inability to deliver anything into production, finger pointing, comments like “we tried agile and it didn’t work” and so on.

Our discovery sprint team started using an example we called the “Tim” story. Tim is one of the executives in charge of the project.

After doing twenty user interviews, looking at code and reading a business case and other artificacts, one of our findings was the project was using a waterfall approach to manage a project with complex business rules, an ERP system. The team would talk about insufficient requirements and failing tests. Everyone was blaming each other.

Our recommendation was for Tim to be migrated out of the old system into the simpliest version of the new system that could be deployed to production. Because the team were working in silos, they had accomplished a great deal in their own silo but nothing worked together thus zero business value had been delivered in two years of working on the project.

Tim would receive his paycheck from the new system and if that failed, he could receive a handwritten paper check, bugs would be fixed and we’d try again two weeks later. Because Tim as an employee is one of the simplest payroll scenarios, the salaried employee with no special circumstances, we described this to the team as “the happy path”. Once Tim was being successfully paid by the new system, the entire management team working on parts of this project would be migrated. This is a way to deliver small iterative value while also demonstrating how committed the executives and team members are to the effort.

Now, a lot needs to happen before Tim can get his first paycheck. The system needs to be deployed to production, how a single employee is migrated from the old system to the new system needs to be understood, there needs to be confidence in the basic security of the production system and more.

As additional groups are migrated, the complexity will increase. For example, an employee that is working two different jobs with overtime and several dependents. They split their paycheck into several bank accounts and had previously worked at the company, quit and has now returned to their old job.

The team should take these complex use cases that the new system needs to support, focus on them as a team one-by-one and see success. They should continue in this “continuous improvement” phase of the project as new groups of employees are onboarded.


Now, contrast the “Tim” story with the project team’s current way of working. For over two years the team has been assembling a complex list of never-ending requirements aspiring to a place where “we have all the requirements” (unrealistic) and “we have confidence the system works for all HR and payroll complexities” (impossible) and “then we can do a big bang cutover to the new system” (dangerous).

When our discovery sprint team talked about the happy path versus waterfall big bang approach in our readout it resonated with the whole team. You saw head nods from non-technical folks, agreement and understanding from Tim and validation from others saying things like “We tried 5 test cases six months ago and they all failed but they were our most complex payroll scenarios involving overtime pay, employees working two jobs and more. We never thought to start simple. This totally makes sense.”

In past products I’ve worked on, I’d tell a very similar story about “how we can take the first $1.” Executives would often scoff at this and talk about how we need to support millons of dollars of revenue and get inpatient. However, it’s powerful. Understanding the first simple flow, the happy path, the MVP, etc is still a great thing to lean on if you are trying to help unstick a giant enterprise project or working on your next small startup.

Using Trigger Lists in Product Management

I’m a big fan of “trigger lists”. The exercise of building them and the value they bring to a Mind Mapping or Design process have proved beneficial to me over the years. One of my favorites is David Allen’s GTD Incompletion Trigger List.

Recently, I transitioned from obsessing over providing Developers with APIs that would help them build amazing things with AI to obsessing about Healthcare and how AI can provide better care while lowering costs.

I pounded a Doppio and spent an hour brainstorming this trigger list to help me empathize with Users and better understand Actors in the crazy ecosystem that is today’s Healthcare tech.

I am a…

Healthy person
Cancer survivor
Factory Floor Worker
CRO Administrator
Product Manager
Community Oncology Clinic
Hospital CEO
CMS Employee
FDA Committee Member

And I have…

Outcome data
Clinical trials
Drug databases
Medical journals
App Store Reviews
Medical Devices
Full Contact API data
Clinical Trial Participants
Patient data
Lab results
Population data
Reimbursement data
Patent filings
Research and Health kit data
Hospital trends
Blog posts
Survey results
Internet searches
Product reviews
Instagram searches
A list of questions

And I want to…

Find Patterns
Organize my data
Filter my data
Search my data
Understand social media
Build an Android app
Surface correlations
Have access to information

So I can…

Comply with regulations
Stay up-to-date
Collaborate with a Physician
Track my progress
Get credit for a course
Be reminded of an appointment
Find cost savings
Sell an app
Make people healthier
Prove a point
Get reimbursed
Understand health trends
Track my Clinical Trial
Find a Hospital
Research and buy my medication
Predict outcomes
Make more money
Connect data together
Build a treatment plan
Find a Clinical Trial
Predict the Future
Support Meaningful Use
Make evidence-based clinical decisions
Analyze adverse events
Provide better treatment “in the field”

For those familiar with Agile, you’ll recognize the “As a User I want” format of this trigger list.

We all have so much stuck in our heads, try creating one of these trigger lists for something in your world and you’ll be surprised at how it can help.

How a pregnant wife helps with software development

My wife is pregnant with our second child, due in May.  For those of you who have never experienced this release cycle, it’s 9 months long and does not have an exact release date.  There’s a thing called “Nesting” that occurs during this time in which a couple works together to get every single detail perfect in preparation for the baby’s arrival.

As I shop for curtains, read updates on the latest in car seat technology and scour color palettes for that perfect shade of blue, I am reminded how “Nesting” plays a serious role in the day to day life of the Agile Product Owner.  As a Product Owner myself, I am not writing the amazing code that drives our application, I am focused on keeping everything in motion and getting all the pieces just right.  As I see our baby room come together in just the right way and our app taking shape so beautifully, I can’t help but feel like a proud papa.

Now, if only I could get my wife to use Kanban.


Building Software is Amazing

For the past 6 months I’ve had the opportunity to work on one of the best projects of my career.  This thing has all the buzzwords: big data, social media monitoring, semantic analysis, kanban, ruby on rails, github, distributed teams, expertsourcing, skype video, lean, pragmatic, platform, you name it.  The team is brilliant and highly skilled in their areas of expertise (rails programming, UI/UX development, architecture).  Each member cares deeply about their craft and is highly passionate about our project.  We argue, we collaborate on great ideas, and all stress the difference between opinions and facts.

This quick reflection just reminds me that building software is amazing.  It’s not writing up exhausting requirements that no one cares about, it’s not outsourcing all of your technology to a vendor, it’s not making stupid decisions that leads to wasting money and not shipping product.  Building software is about being creative, respecting the craft and the team and adapting quickly to a changing environment while relying on tried and true principles.  I can’t wait to see what shows up in the next “git pull”.

Why GTD Projects and Agile User Stories are so similar

David Allen’s Getting Things Done (GTD) approach reiterates the challenges of breaking a Project down into Tasks.  He focuses on the psychologic barriers people have with the work in front of them.  A common example (I’m paraphrasing here) is a person adding “Mom” to their ToDo list.  When digging further, David discovers that “Mom” really means “Mom’s birthday is coming up” and there are no Tasks or “Next Actions” defined to move the Project closer to completion.  This avoidance is very stressful on the person and a very inefficient way to life a busy life.

We use Rally’s ALM product and the Kanban custom tab to manage our User Story development.  I have worked with 2 teams over the past few years and both I consider quite amazing and talented.  Ongoing debates about naming conventions for User Stories, the importance of Tasks, and who should be the Story Owner have never been resolved.  Our teams crank out great software, but always within a stressful environment.

As I was enjoying a nice bike commute into work last week I was listening to the GTD | Podcasts episode titled “The Do Lectures”.  Around minute 10:30 David Allen says that to clarify anything, you have to decide “What outcome are you committed to finish about this?”  I realized how similar GTD Projects and Agile User Stories really are.

  • A GTD Project clarifies the outcome you want.
  • An Agile User Story describes what the User wants to achieve.

Both GTD Projects and Agile User Stories use Tasks as a method of describing the work required for completion.  In both, Tasks probably need to come in some sort of order, will vary in their scope and may require different people’s resource.  Also in both, if Tasks can be defined it signals a complete understanding of the work to be done.  Granted, you may have missed something, gotten something wrong or encounter changes along the way, but at least you’re on the right track.

My experience in working with fellow Developers is that being asked to Task out a User Story is sometimes treated as some kind of insult or waste of time.  We joke a lot about a common Task name we use in Rally simply titled “do it”.  Again, the GTD project similarities are strong here.  The initial reaction is to keep things in your head and resist verbalizing the steps required to complete the work.  Instead, insist on breaking every User Story down into Tasks and agree that the first Task to be worked on or “Next Action” is the most important one.

By leveraging the GTD Projects similarities in your Agile team, hopefully everyone will be more efficient and less stressed!

What Brad Feld and Mark Suster think about Product Managers

I was watching This week in Venture Capital #18 with Brad Feld hosted by Mark Suster and was pleasantly surprised to hear “Product Manager” pop up as a topic. At minute 47 of the interview, Mark asks about the “lack of experienced Product Managers”.

Brad says “One of the hardest roles to fill in a startup is that of an experienced Product Manager.” He goes on to say that one can be trained to be a good Product Manager but that person needs to have a certain personality type. Brad cites a quote from Mark Pincus “Be CEO of your job” and goes on to say “If you are a Product Manager for a specific thing, you have to deal with it just like a CEO has to deal with the whole company.”

Some personality traits that do not help the Product Manager are:

  • too process driven
  • not a good mixture of leadership and management
  • not willing to be uncomfortable creatively with it then button down to drive to the goal line

The conversation wraps up with comments on the changing approach to Product Management as the role has become very formalized in big companies. Brad and Mark talk about the older Product Manager/Project Manager setup at Microsoft and the how today’s “Google style” Product Manager is a very different personality type in a very different role. Mark argues this type of personality (product, engineering driven) is not focused enough on the economics of the business and then Brad counters by saying that he would take a call from any Product Manager for a product at Google in a heartbeat. Brad concludes the conversation by reiterating the notion of owning the whole function and knowing how to allocate resources is a powerful skillset and a “very hard role to find”.

Creating Project Rhythm by following TechStars and Y Combinator’s lead

I admire TechStars (wearing my TechStars t-shirt proudly) and have been a reader of Paul Graham’s blog for years.  Both programs have created a vibe and atmosphere that churn out great work and provide endless motivation and contributions to their surrounding tech communities.

Reading the latest post from Paul Graham titled “What happens at Y Combinator” highlighted the relationship between schedule and rhythm and the role this plays in projects.  Both the Y Combinator and TechStars programs are roughly 3 months long, similar to the quarterly Agile Release schedule that we use.  The rigid schedule both programs use inspires and creates massive pressure for teams to work hard and deliver.

Because teams in TechStars and Y Combinator live and breathe their projects they are able to devote almost all of their time to it.  The rhythm these programs develop include dinners, hackathons, presenting at local tech meetups and renting out conference spaces to host big demos.  While a typical team can’t take things to that level, there are lessons to be learned.

Here’s the schedule I am using for our new project:

Product Summit – beginning of Quarter
A 2-3 day onsite working session full of multiple topics (business and technical) with a tight agenda and after work dinners.  The goal of this effort is to have a general gameplan for the upcoming quarter for the whole project, not just development.  In a distributed team like ours, it’s a rare chance for the entire team to spend time together.

9 Weeks

9a – Project Management conference call – a weekly update of anything to do with the project including budgets, contracts, etc
9:30a – Daily Standup

9:30a – Daily Standup
10a – Weekly dev team meeting – a weekly meeting to discuss technical details of upcoming work, review Kanban Board and Release Burndown

9:30a – Daily Standup

9:30a – Daily Standup
Noon – Weekly demo to Stakeholders
1p – Weekly call with a Customer

Release retrospective – end of Quarter
A 2 hour retrospective answering questions like “What did we accomplish?”, “What was our Velocity” and “What can we change in the next Release?”

The rhythm I am trying to build for this project begins with a big kick off because lots of things need to be figured out up front and agreed on, then a strict weekly schedule to pull everyone along when things start to fall off the rails, then a decompression and review to let the dust settle. The schedule I have designed is nowhere near as cool as TechStars or Y Combinator but it’s a step in the right direction (I hope).

Related Articles:

The Rhythms of Life on

Being more Productive on


What the dude at Salvagetti bike shop asked me that most Agile Product Owners don’t ask Customers

A few days ago I took a stroll down Platte Street in Denver and stopped into Salvagetti Bike Shop.    The conversation went like this:

Shop guy: “Hey man, what brings you in today?”

Me: “Beautiful day, out for a walk and felt like spending a few minutes surrounded by bikes”

Shop guy: “Cool.  If you have any questions about what you see, don’t see something you were hoping to see, or have suggestions to help us make our shop better please let me know”

I was strolling away from him the same way I do every time I’m in a retail store and don’t really feeling like dealing with anyone.  When he asked me my opinion I immediately turned around and began talking to him.

“You guys should rent high end road and mountain bikes, I would spend a few hundred dollars a summer with you.  Do you have baby bike strollers?  I just broke my helmet and need a new one, any recommendations?”

Bike shops are everywhere in Denver.  Heck, within a mile of our office there are about 5 places I could spend $$$ on bikes and accessories.  I am now going to spend my money at Salvagetti because I love their attitude towards me, the Customer.

After my trip to Salvagetti I began thinking about the Agile gospel I read over and over about soliciting input from your Customers, Stakeholders, etc.  It’s true, getting ideas from Customers is super important in the world of software and services today.  Along with Customers giving you great ideas for products and features, they are also feeling good because their opinion is being heard, the same way I felt after leaving Salvagetti.

What does a Product Owner do?

…continued from Part 1, What is a Product Owner?

As I strive to improve my role as Product Owner on our Scrum Team (“Agile”), I thought it useful to create this list of things that a Product Owner should do.

1. Create a Product Roadmap to articulate Product Strategy “as we know it”
I recently had a great email conversation with Kevin Donaldson, VP of Product Management at Balihoo. Kevin outlines his view of a Product Roadmap:

“I create a Product Roadmap to articulate Product Strategy as we
believe it to be right now – it maps market events, architecture,
features to a market map (who benefits). As you know it isn’t meant to
be a project plan – it’s a view of the world that we update each quarter
to help show our product strategy and vision of where we are heading (at
least based on our current knowledge of the market).”

I think this is a great summary from Kevin. The Product Roadmap can be used to guide other parts of the Product Owner’s job. This is something that should be internally public, so post it to your company’s wiki or intranet.

2. Host recurring Product Council meetings
The Product Council is made up of key Stakeholders from Sales, Customer Support, Marketing, Technology and Corporate Strategy. Use this meeting to provide updates to the group (usually consists of execs who won’t read your Release/Iteration notes), prioritize themes or epic features to prepare for your next release and ask/answer questions about the products you own. The Product Council helps steer you in the right direction. During this meeting, continually refer to the Product Roadmap you’ve created.

3. Have a good Release Planning meeting with the Team
One of the hardest parts of being a Product Owner is elaborating User Stories ahead of time so you can make decisions about what should go into a Release. The Release Planning meeting is hosted by your team’s ScrumMaster but you do most of the talking. The team asks you hard questions about specifics that haven’t occurred to you yet. You will be slightly embarrassed as you realize certain Stories are not well elaborated and you are not as prepared as you thought. Come out of this meeting with Plan Estimates for every Story inside your epics or themes. Usually we have 5 or so “Children” Stories for each “Parent” Story (we use Parent Stories to capture epics/themes). I have yet to see the team 100% committed to what we discuss during Release Planning. This meeting seems to be about helping me fully vet out everything and rough out a Release Plan.

4. Publish your Release Commitments internally
Create a blog post, etc that describes in English the stuff you plan on building in the upcoming release. Group things by Product or Function and make it a very easy read. Who does this feature apply to, give a one sentence “business intent” or “benefit”. Be careful how you write this because you are really “committing” to this and everyone will refer to this post in the future to gauge your success. I have had killer releases where everyone was cranking and we didn’t deliver on things in the Release Commitments, usually because the thing became irrelevant something before we began. Anyway, it still felt like we did something wrong during the Release because we had published that we would complete that thing.

5. Have a good Iteration Planning meeting with the Team
Iteration Planning happens every 2 weeks on Tues for our team and is taken very seriously, this didn’t used to be the case. Tues is great because it gives the team Mon to get loose ends wrapped up. As a Product Owner, you need to be ready to talk specifics about each User Story you have slated for the upcoming Iteration. Besides talking about the Story and what it will do, be able to answer 3 questions 1) Why are we doing this? 2) How will this be tested? and 3) What is the definition of done? I know many will argue that 2) testing is the responsibility of the QA lead however, I have noticed that the Product Owner’s understanding of how everything fits together directly relates to their understanding of how a new something should be tested. What other parts of the app is this new thing going to impact? How will users be using this new thing?

Never come to Iteration Planning with an Iteration overloaded with Stories. You need to understand your Team’s velocity so everyone on the team can be realistic about what will get done in the next 2 weeks. At the end of Iteration Planning, you should have a well tasked, well understood workload for the team.

6. Publish your Iteration Notes at the beginning and end of each Iteration
Export your list of Stories and Defects committed to during Iteration Planning and upload to your company wiki, etc. I have found this doesn’t need to be a detailed blog post, just a communication to the company so certain people who are waiting on specific items can scan the list, ask you questions, etc. At the end of each Iteration, create a blog post similar to your Release Commitments called Iteration Notes that summarizes in English what you accomplished, how it will be rolled out, who it benefited, etc. I have seen people print out the Iteration Notes I publish and keep them at their desk as they respond to support questions or talk with a new prospect.

7. Attend Daily Standup
In a lot of the Agile literature I’ve read it seems the Product Owner is expected to checkin at Standup from time to time but not be there everyday. The best Iterations our team has is when everyone is totally engaged and attends Standup everyday, including me the Product Owner. Standup gives me a feel of how things are progressing, helps me answer questions and make decisions about Stories on the spot to keep the team cruising along, and is a motivation for making sure my Tasks are getting marked complete (usually I have a few tasks during an Iteration).

8. Host the Iteration Demo
Every Wednesday our company has a “Lunch n Learn” in which pizza or burritos are brought in and we all sit in the conference room to have lunch together. Every 2 weeks I have an Iteration Demo in which I pick relevant Stories and Defects to discuss from the previous Iteration. I have tried to host this meeting a variety of different ways and was never able to get a good attendance, a company lunch is a great way to get people in a room to listen to you for a few minutes. The questions I am asked about each Story, even ones I felt were well elaborated, often surprise me. People bring up a scenario that has happened in the past 2 weeks since we decided to build the Story that challenges it’s usefulness or changes how it needs to work. The Iteration Demo is the best way to validate what you are building is actually good. Be well prepared for this meeting, don’t use slides, have the software up on the projector or web conference for people to see you clicking around, and don’t rush through. The best questions usually come right as I am about to move on to discuss the next Story.

9. Control Product Rollout and Production Deployments
Each company is different, you may have a Product Marketing person that helps you announce new features, you may publish to a Customer facing Product Blog, you may do nothing, in any case you are still managing the rollout of features including what code is deployed to production and the timing of everything. I include a brief summary of how each feature will be rolled out in my Iteration Notes (see 6.) as we roll some features into some products and not others. Every Monday, the entire team has a Production Push meeting in which we review each SVN checkin to make sure it has been tested and is ready to go to production. Although the Developers and QA team members are the ones talking and our ScrumMaster leads this meeting, the Product Owner is making the final decision of what should be deployed.

This list above assumes the prerequisites for being a Product Owner are already happening: absorbing everything about your industry, engaged in everyday discussions about product ideas, using the software you build, using lots of software you don’t build and so on.

Are you doing all of these things as Product Owner?

See a list of related articles I’ve tagged Agile

What is a Product Owner?

In the Agile Software Methodology there is a role called the Product Owner.  This is a new version of the traditional Product Manager.

My interest in team roles began after reading “I Sing the Body Electric: A Year with Microsoft on the Multimedia Frontier” by Fred Moody.  Moody spent a year with a team at Microsoft observing them building a children’s encyclopedia product code-named Sendak (Encarta Junior).  The team was a mess and the project was a stress filled 2 years of seemingly bad decisions and unhappiness.  I won’t ruin the ending but highly recommend this read.  This book highlights the Product Manager role and how they work with the team.

As I pondered the Product Owner role during my run this morning I came up with these flavors of the same thing:

Army of One

This is the person that calls themselves a Product Owner but is basically told what features to build, writes the code and is responsible for testing everything with no help.  This is typically seen when organizations “adopt Agile” but are still small without the cash to hire multiple developers and testers that round out the team.

Dev Team Project Manager

This is the person who works on a proper Scrum team, works with Stakeholders to define priority and is doing many things right to produce results.  They are really a Project Manager that is lucky to have a killer team, especially ones that have Designers on the team to elaborate the User Stories.  The team is humming along well under this person’s direction but they can probably be replaced without too much impact.  Companies usually pair this person with a Business Analyst or Product Marketing person.

The true Product Owner

This person possesses a deep technical knowledge of the Products they are working on, has a strategic mind with an understanding of their marketplace and can talk to Customers.  They are focused on one product or product family, come up with their own ideas as well as translate input from Stakeholders and are a thought leader in the space.

I was very inspired by this WWDC video featuring Werner Jainek of Cultured Code.  He speaks as a true Product Owner.  Listen to how he easily explains why Things for the iPhone is important by saying “tasks hit you while you’re walking in the city or in the store buying something”.  Then he discusses the iPhone SDK and it’s importance to the success of Things, and concludes with analysis of the marketplace for ToDo List software and the impact of the iTunes store as well as the price point they selected for the app.

Of course, each organization is in different phases of their life and has resource constraints, not everyone is the same.  What type of Product Owner are you?


Read Part 2, What does a Product Owner do?

Read articles I’ve tagged about Product Owner and Product Management