Ship Early – Why New Software Sucks

Reading time ~ 3 minutes

I’ve been working in software product development companies for nearly 20 years.

Until 4 years ago I’d always been involved in “enterprise” software.

You know – the monolithic systems with great reporting capabilities that sell well to managers and (at least historically) poor UX for the real users. Those same products that promise the moon during slick demos, require 6-12 month sales cycles where complex pricing structures are worked through and year-long implementations are agreed.

I’ve helped set up demos, I’ve watched amazing presales engineers work all night to rewrite chunks of an application to demonstrate to a prospect that it’ll meet their unique requests.

And then during implementation you discover some of it just doesn’t work.

I implemented one company’s products internally. Dogfooding from the day V1.0 was released. In 6 months I raised over 50 showstopper bugs (almost all were found by their first real customer not long after us). On a visit to HQ in San Francisco, after a fair bit of wine at a great Italian restaurant in Burlingame (the House of Garlic if I remember correctly) I challenged the then VP of Development for that application on why they shipped blatantly unfinished software.

His answer was simple,  logical and for a young, inexperienced graduate analyst programmer my first window into the commercial realities of product development. He said;

“Market timing”

“If we released when the software was actually finished, we’d be beaten to market by our competitors.”

“It’s acceptable business practice because it takes 6 months to sell and we can’t start selling until the product is released and in our price books.”

“Even after the sale it takes months to implement so by the time users are ready to go live we’ve fixed all the major issues because you guys are dogfooding it for us”.

It made a whole lot of sense but it wasn’t something they ever told us on the project!

The thing is, everyone else is on the same bandwagon and the escalation games start rolling.

Products are brought to market earlier and earlier in their maturity with the knowledge that “nobody trusts a v1.0 version of a product anyway.” It continues today. Many large banks won’t touch an x.0 version of a product until the first major maintenance release is shipped.

My experience was the same. In most companies I worked for; when a new release of the DB platform shipped, we’d plan on adopting it sometime after the first 6 months out in the wild when we knew it was stable.

The game has moved on. It’s no longer just products that take a year to sell and implement so our exposure to early releases is increasing and in general so is the entire industry tolerance (there are obvious exceptions in safety-critical systems).

In my time at Oracle in the late ’90s I saw them try to change this world. They had a vision known as”Gray Iron”. It seemed brilliant – for business, development teams and customers. The idea was that based on a playbook of “best practice” business processes a customer could buy a server entirely preconfigured and working out of the box to support their entire financial, ERP and CRM set of processes. They could simplify the pain of users, ensure quality was high and radically reduce implementation times. Obviously this also offers a great potential competitive advantage.

Sadly it didn’t take off. Competitors were still playing the “ship early” escalation game so we had to play too – the poor system fed itself.

The surge of change brought about by Eric Ries’ book The Lean Startup has fanned the flames of this mentality. Ship early, get customer feedback and adjust.

The sad thing is this used to be only in the enterprise market but the world has turned. Consumer electronic devices now face the same market timing escalation issues as this article from December on Forbes highlights.

It’s now common for us to expect our phones to need a reboot or crash and even for consumer software to have significant glitches.

It’s great for the pace of innovation but spare a thought for the end users and customer support teams.

It’s a commercial reality we can’t avoid but let’s make sure we’re not sacrificing the end user experience. If you must use your customers as lab-rats, let them opt in or out of your experiments. Let them decide if they want “bleeding edge”, “new” or “stable” and honor their wishes.

If your product is even remotely valid you probably have enough early adopters willing to validate the bleeding edge without sacrificing laggards on the altar of possible futures.

What’s your “ship early” policy like?

Manage Your Product Portfolio Like an Investor

Reading time ~ 8 minutes

A bit of a ramble on portfolios.

Every time I return to the draft of this post I tweak, rewrite, remove and add. Today I decided it’s better to ship “good enough” and move my investment elsewhere. I hope this still delivers enough value to you as readers…

Even with a good investment, wouldn’t you want to increase your chances of success?

I’ve been involved in annual and bi-annual portfolio reviews of varying quality over the last 7 years and been in the fortunate position to change and improve how many of those have run. With every review I think about how we can do a better and quicker job.

If your portfolio is anything like those I’ve seen in both my current and last employer you’ll have a mix of “no-brainers” and speculative work. Often those are run through the same process with mixed results. You may even have the luxury of standing teams from some areas.

When a project or bid reaches review, on the surface it’s in the proposer’s personal interest to minimize the level of scrutiny their plans receive. They’re busy trying to deliver a business and want to get their project moving fast.

I regularly see plans proposed at portfolio review that magically change within 2 weeks of starting and again within a single quarter. I’ve even seen plans delivered “late” and miss large parts of a review cycle and yet still be approved.

A cynic might say that the owner has secured their funding, now they’re free to change! Less cynically, this is simply what happens when early-stage plans and new projects hit reality. With the review cycle over the same apparent due diligence no longer comes into play.

With peer reviews of code, good reviewers are well-practised in what to look for and may even have checklists and standards. What tools, checks and support do reviewers of your portfolio have? Do they really work?

I frequently see other portfolio “smells” too.

  • Where a project is a continued investment in an area already in progress, these are often a shoe-in for the next cycle. This can turn into sunk cost behaviours.
  • If a project is recently started, we may simply assume that because the project is only just under way that we need to “leave it alone” and that it may be unfair to re-scrutinize a business case and plan.
  • Large revenue increases are predicted against short time scales on the promise of a new release. The time for these increases to actually occur is much longer. Furthermore, these are usually single-point commitments without agreed tolerances or ranges.

I’ve had the luxury in the last couple of years of being in a company that has a track record of actually shutting down projects early (occasionally not early enough) when claimed benefits fail to materialize or overruns occur, Yet even when those projects were set up, bold forecasts were made and operating tolerances against those forecasts were not negotiated.

I’m torn. Proper due diligence on all investment decisions seems obviously right but the case for funding a standing team to continue driving a nascent or even successful product forward is strong. As my CEO said to me recently – “It’s very hard to resist the man with the plan”.

The “VC” Investment Philosophy

Consider your product development organization as a Venture Capital company.

Every year you review funding and invest in a variety of options. Like VC, a smart portfolio and balance of risk/reward is important. You make some investments to sustain cash flow, some for organic returns and you hope to find the occasional (and mythical) “hockey stick” growth curve.

Balanced risks and a mix of investment durations is needed for a sustainable business and a regular review of those decisions is vital to your operating health. You may choose a multi-year investment in a loss-making area believing it’ll come good in future or drive sales for other products.  A year later the climate may have changed or the market may not have materialized. Do you kill the investment or ride it out? You can’t answer this question without understanding the context of the rest of your portfolio.

If it were lightweight enough and delivered better decision-making, I assert you’d want to your review your investment much more frequently. In my simplistic view of the world it’s like the different between a basic index tracker and the increased cost (for potential better return) of buying into a managed fund.


Treat your portfolio like a VC investor, consider taking every new product release (including new releases of existing products) like you’re going back to the dragon’s den to bid for another round of funding.

Don’t commit all your capital on an annual basis unless there is a truly sound reason to do so. Seed your investments with an option to increase investment in future or kill it early if it no longer looks valuable in your portfolio  (Real Options anyone?)

Picture this rather extreme “Dilbert” conversation…

– I want to improve my existing product, can I have some money to take these improvements to market?
– Sure what’s your business case
– Well the product is already in the market and profitable, I don’t know who all my customers are but I have lots –


I can’t tell you exactly which of my products is bringing the money in because we package it all up together under a single product line but all those existing customers give me support money every year.


They raise enhancement requests that they never expect to get fixed because we take so long to deliver and all new features we deliver are never on their version anyway.


Most of them don’t have any immediate plans to upgrade so basically we’re making millions from fixing defects and taking support calls. But I’ll make you a personal commitment to 1000 new customers as long as I can get every “must have” feature in the backlog implemented in a year.


And if I don’t meet my numbers it’s because we didn’t get all the features implemented
– Ok, I’m feeling flush and can’t be bothered to visit the race track this week – here’s a year’s funding,  I’ll see you in a year.

Let’s try again on some sounder (but still not perfect) footing…

– I want to improve my existing product, can I have some money to take these improvements to market?
– Sure what’s your business case
– Well, we have 200 customers on out of date releases. They have no immediate incentive to upgrade as what they have meets their needs but upcoming regulatory requirements plus opportunities in their markets mean that they will need to change and add the following 10 business processes.


Right now these are manual or slow and cost them on average $1M with a 3 month cycle time.

In order to take a viable upgrade to market we need to show a return on investment to our existing install base.


We believe with the right level of software support we can halve their costs and reduce cycle time to 4 weeks for the top 3 of these processes.

Providing this ROI to our existing install base will preserve M&S revenue.


Moreover, here’s the list of RFP responses we can’t compete on (and their value) due to these processes not being supported right now.


If we modularize these features and deliver them sequentially, here’s the first round of prospects we’ll be able to work with – plus we can charge an additional premium for some of these features.


Based on current team velocity and backlog, we’d like to focus on delivering a minimum marketable feature set by the end of next quarter to meet the top priority business processes however there’s some viable value-add work that we want to move forward on, can we have 6 month’s funding now and an option of a further year if we’re successful?
– Ok, I’ll tell you what. Here’s 4 months funding. Let’s have a checkpoint review in 3 months and assuming you’re within 20% of your target we’ll immediately release a further 3 months (7 in total).

If you can deliver on those, I’ll make sure you’re on the fast-track priority list for the next round but if things aren’t going well at the end of 6 months we’ll need to either shut the work down or push for a hard reset.

How soon can you have something to show me?

I’m grossly exaggerating and over-simplifying. It’s an extreme example to illustrate a point but which is a more compelling business case and conversation?

  • Which has clear priorities, measures of success and is believably achievable?
  • Which would you invest your personal million dollars in?
  • Which is more likely to be set up for success?

The impact of governance on portfolio and product management

Let’s assume your governance system is broken and you can “get away with” the first case. There’s more to explore!

Let’s imagine both of the above were products in the same active portfolio…

Scenario 1:  – Portfolio resourcing and opportunity cost
I have a constrained resource – developers. I can choose to invest those staff across all products in parallel and deliver slowly or focus on a smaller set, deliver faster and then move onto the rest. I know I want them all but surely there’s an absolute priority. Considering the business cases above, which will allow me to prioritize better?

Scenario 2:  – Portfolio investment in a downturn
We’re in a big economic downturn, our numbers are looking bad and we need to start cutting investment fast. Looking back at the business cases for our existing portfolio, which should I take out first and which should I keep?

Scenario 3:  – Portfolio collaboration in a tight market
We’re in a business team where each of us owns a given product or number of products. Again, the market is tight. Ours was the first business case above.

We have a choice. Fight our corner for our product’s success or collaborate with our peers to set up the best selection of new product releases based on overall market trends, install base, requests etc.

If we fight our corner, we risk sub-optimizing around personal goals at the expense of the entire group’s success. If we collaborate, we won’t get a new release for our product this year.

Which is the “right” thing to do?

Scenario 4:  – Improving product quality through your business case.
I’m a developer on a team. I’ve been working with the same product for 5 years adding new features continuously.

I like my job and want to stay. I don’t question why we’re adding new features, I’m sure there’s a good reason and I’m told that’s up to “the business” to decide.

I’m now halfway through writing a new feature and I don’t know what the user is actually trying to achieve.

Given the above business cases:

  • Which is most likely to have backup information that allows me to make a sound implementation decision quickly?
  • Which one has users I can talk to?
  • Which is the more motivating product to work on?
  •  Which one am I likely to actually care about any deadlines or commitments for?

 So What?

A sound business case** is just as vital to an agile team’s success as it is to our portfolio decisions. How many times are engineering teams really engaged in the business case for the product they’re working on – or are even able to challenge parts of it?

**When I say sound I don’t just mean it has great projections, I mean it stands up to truly solid testing – try the 200 questions technique for testing a proposal.

  • In your organization is it their place to do so or none of their business?
  • Is it more cost-effective to keep them out of the loop?
  • Really? How’s that working out for you?

We need to understand and explain what really meets our customer’s and our own business needs. Did the last release fail to solve their problems or do they have new issues?  It’s not just what “features” (and how many) the next version of the product should have. It’s who do they impact & how and should we even have a new version of that product right now relative to other priorities.

Time to re-check your governance systems and start thinking like a VC. Set up your funded start-ups for success, actively manage the portfolio without wasting resources, engage experts in decision making and business support and where a real new opportunity is seen, don’t just fire a single shot, try a spread bet on that market.

Beyond the initial investment, good VCs offer support, mentoring and critical feedback. They don’t just hand over money and quietly hope their horse will come in at the end of the race.

If you’re on any kind of portfolio review, do a proper job, ask tough questions and make sure your business is making sound decisions.

All of us as reviewers are empowered to do so, don’t let precedent or pressure erode your business sense. It’s our responsibility to test, challenge, verify and make sure we’re investing in the right spread of activities.

Be brave.

If you can’t see the value in an investment or feel your money is better spent elsewhere, tackle those issues head-on.

Some thinking for you.

  • Are your portfolio reviews being gamed because of a poor periodic funding cycle?
  • What operating tolerances have you agreed for each of your investments?
  • What would need to happen for you to be able to easily review your portfolio more frequently?
  • In your current portfolio are there any investments that smell bad?
  • Is your portfolio a good balance of risk, reward and cycle time?
  • If you had to shut down 10% of your projects next week, which would they be and where would you reassign that investment?
  • What critical questions do you (or should you) be asking of any investment?
  • Do those questions change depending on the type and scale of investment you’re making?
  • Are you truly “empowered” to change any of these things?
  • Who do you need to discuss this with?
  • What would really happen if you tried?
  • If you could change or improve 3 things in the way you review your portfolio, what would they be?
  • What’s truly stopping you pushing for those changes?

200 Questions to help bridge the Product Owner divide

Reading time ~ 5 minutes

A year or two before I first started writing publicly, I read an interesting, varied and quite long essay by Jeff Patton on the Product Owner role in Agile development (particularly Scrum)

Whilst there are some areas I agreed with, the discussion on “heroics” was an area that left me cold. In my opinion, great software teams don’t have space for individual heroics and (in my opinion again) the sustainable pace ethos generally also plays down team heroics (but that’s a debate for another time).

There was a comment in Jeff’s article that resonated with me that I made a note of at the time. Years later it’s still highly relevant and I wanted to re-raise it this week in the context of recent challenges I’ve been facing.

“For the product you’re working on right now, how will your company benefit after the product has shipped? If you understand how, do others?”

Although this question was aimed at Product Owners it’s something I’d ask all development team members to really think hard about.

Now go further. Are you solving technical problems and a series of requirements to ship a product release or do you really understand the value of the release you’re working on, its reason for being developed and its impact on specific customers, the market or the company?

How many times have you or your team examined the reason for delivering a release with a specific set of features and understood their aim, questioned the backlog and vision and better still, properly understood what you’re trying to deliver in terms of solving the needs of the user?

When I say “understood”, I mean really understood – not just prettied up to follow one or another user story format.

Consider this an opportunity to pause for thought.

Back in 2013 I attended a Retrospective Facilitators Gathering and was introduced to an amazing concept over lunch by Willem Larsen that he described as “200 Questions”. He explained an idea that comes from animal tracking.

When tracking an animal you explore the environment in a way that an every day person doesn’t even consider. You look at every twig, leaf and blade of grass and ask questions of how it came to be in its given state (and why) in order to determine if you’re on the right path.

My translation of this to my own work is to try and develop a genuine and deep curiosity for every item you look at. (Even if you don’t have time to answer all your questions)

At the same lunch, we tried it with a salt cellar

How many people have handled it since it was made?

Who designed it?

What inspired the design?

What’s it made of?

Where did the salt come from?

What process did the salt go through?

(we lost count of how many questions we asked)

Applying this same healthy curiosity to incoming product features or requests is incredibly powerful.

You know things are wrong when every request coming in is essentially a specific solution being proposed.

And you know how translating feature requests back to user stories in anything except a shopping cart or finance trading application seems to be really poorly explained in the agile community?

Try this as an experiment for getting unstuck…

  • Set yourself a target of asking 200 questions about the next big item coming in to your team.
  • Try different “lenses” for asking the questions (much like 6 thinking hats)
    • The “User” lens
    • The “Investment” lens
    • The “Functional” lens
    • The “Market” lens
  • What questions logically follow from those first “level 0” questions?
  • Decide which of those are important and valuable to actually answer in order to further your understanding towards your goal.
  • Work on answering them – collaboratively.

In no particular order (but with some logical grouping around lenses) and in the very rough form I’ve been actively using in my current team, here’s over 50 of the “level 0” questions I’ve started experimenting with.

Feature Info

  • Name – what do we call it?
  • What is it? (2-3 sentence user-facing description *and* 2-3 sentence product description)

User info

  • Describe how a user would do this now? (without new code)
  • What types of users does this help?
  • How does it help them? (what does it enable, unblock, simplify etc.)
  • What is a user trying to actually achieve when they do this?
  • Why?
  • What constraints are they facing at that moment?
  • Who can we talk to about their goals and needs for this? (a selection of people willing to talk to us more)
  • How complex/accessible (to the user) is it?
  • How many/what proportion of users will benefit from this?
  • How frequently might we expect different types of users to use this?
  • How might this detract from the product for other users?

Investment/Product/goal alignment

  • How does this improve the product?
  • How big/expensive is it?
  • How much time do we want to invest in initial investigation?
  • If an initial investigation is inconclusive, what next?
  • How much are we willing to invest in this? (and how flexible is that decision)
  • Is there anything obviously more important/valuable/beneficial to do before this?
  • Would we be fools not to do this in the next 90 days? – why/why not?
  • If this were the only thing we did in the next 30-90 days, is this the right thing to do?
  • Why is this valuable to the team/company?
  • How does it align to current product/company goals?
  • How does it further our journey toward those goals?
  • Would you describe this as a tactical or strategic change?
  • Why?
  • Does this really fit within the product we have already?
  • (how) will it help differentiate the product from the competition?
  • Could this be a new product?
  • Are there any other products it may integrate with or impact? (ours or elsewhere)
  • Does this align more closely to another product than this one?
  • Do any of our competitors already do this? (and how)

Functional info

  • What solution options exist already?
  • Can you give an example of how that would work?
  • Under what situations might that not be suitable/successful?
  • What additional solution options can we think of
  • What’s the smallest simplest thing that could possibly work?
  • What’s “good enough” to meet customer needs?
  • Is there an 80/20 solution option for this?
  • How can we make this more discoverable, useful and valuable to users?
  • Is there an ingeniously simple solution for users?
  • What would it take to make a user say “wow!” (and is it worth the extra effort?)
  • What is the best solution in terms of cost/functionality/usability/quality balance
  • What performance and quality criteria do we have for this?
  • What is explicitly out of scope?
  • Are there any cross-cutting or performance risks?
  • Are there any other significant risks to be investigated?
  • What dependencies exist?
  • If we ship an incomplete solution, what is the follow-on plan and forecast cost for completion?


  • What is the market demand for this?
  • Is there any market or customer sensitivity around timing for this?
  • What marketing is planned or expected for this feature (if any)?
  • How do we expect our competitors to respond to this?
  • For what we’re planning to deliver, what do we expect from our users on social media?
  • How will we launch this feature (alpha/beta/freq update/big bang etc)?
  • How will this impact our position in the market relative to our competitors?
  • What impact are we expecting on sales/renewals by announcing / releasing this feature?
  • What impact are we expecting on our reputation by announcing / releasing this feature?
  • How will we sell / price this?

It’s a lot like writing 10 minute test plans – so quick and so powerful.

Give 200 questions a try on your next big feature request.

The Flat-Pack User Experience

Reading time ~ 3 minutes

Some things in life cause more stress for me than others.

Building flat-pack furniture is for some reason way up there on my stress-o-meter.
Back in November (when I first drafted this article) I bought myself a new laundry basket, it’s quite a nice wooden box with a flip lid. When I collected it, I discovered it was a flat-pack.

I’ve been confronting a lot of longstanding issues recently (one of many reasons for being so quiet on the writing) – this was the second time in a week I’d had to build furniture.

“What’s this got to do with software?” You may ask.
Everything – not around writing it but around your customer and user experience.

Experience 1: The Charity Shop Bed
I bought a bed from a charity shop, it wasn’t cheap but it was nice. I was expecting it to turn up partially assembled (as a second-hand piece of furniture)
To my mixed surprise and dismay it arrived still completely wrapped but with one box opened.


I had to face my fears – get on and build.
I reached about 90% done and discovered an important (but not obvious) piece missing – a central leg.

AAAAAGH – All those stresses and fears were confirmed

Yes, I should probably have checked all the parts were there before starting but I was in “JFDI” mode after building up the momentum to even start!

I called the shop and politely complained.

After 2 days of chasing around, the shop were unable to find the missing piece so they gave me their display model instead.

There’s a couple of mixed experiences here…

First, I hate unfinished jobs. Sitting in my room with a part-made bed with the frustration of the missing parts and the belief I’d bought a cheap secondhand bed didn’t sit well with me. Whilst looking online for replacement parts from the manufacturer I actually found the same bed brand new for £50 less.

I buy furniture from charity shops expecting it to be cheaper and not new. I also expect it to be as seen in the shop (and not have to build it myself). Otherwise I’d have shopped around online. – Beware

Second, I hate complaining, I hate asking for things. This issue put me way out of my comfort zone. The manager of the shop was exceptionally helpful, professional and apologetic. She clearly went way out of her way to spend 2 days with staff trying to track down the parts in their storage warehouse before arranging a replacement. The time lost was frustrating but as I didn’t yet have a mattress I wasn’t too annoyed.

What really made the difference though was her manner, tone on the phone,  complete reassurance and commitment to a successful outcome – the sort of behavior I expect when dealing with a business supplier, not a charity/thrift shop.

Experience 2:  The Laundry Basket
By Contrast, my cheap laundry basket was a joy. I wish I’d taken a picture before it was assembled.  Every part was clearly labelled, bags of components and fixings were grouped independently, packed in easy to open bags. There was even a bag labelled ‘spare parts’

It got better. The instructions were incredibly clear and precise. A paper ruler was provided to aid differentiation of screw sizes (although with the independent bags, this wasn’t a problem). Where there were 2 almost identical parts, an additional note in the instructions indicated exactly how to differentiate the two.

OK so I was alone and it was a dark evening but the exceptional user experience of that small laundry basket really helped finish off what had been a successful day in such a positive way that it even inspired me to start writing again.

Lesson – those small things that give your customer/user a positive experience after you’ve taken their money and when they’re expecting far worse really do stand out.

Building a Case for Change

Reading time ~ 3 minutes

I recently led a short evening session discussing strategies for collective code ownership. We opened with a set of patterns and practices but the team highlighted something painfully obvious that I’d overlooked…

What’s the business value and driver behind collective code ownership. What’s in it for your product owners and customers?

So often we focus on the people barriers and technical challenges to collective code ownership without recognizing that the barriers may be organizational or financial.

This challenge happens when you attach yourself to “the right thing to do” and seek to progress without recognizing that the population you’re likely to be working with will fall across a spectrum from complete support, through “don’t care” to disagreement and dissent.

If you want to pursue a strategy for collective code ownership, step back and work through the following questions (some of these are hard – consider starting by brainstorming with a small supportive team):

  • If we just got on did it, would we be successful?
    • Yes – Great, you’re working with a team and business that “gets” this or trusts you to do the right thing. You could stop reading here, but you might want to skim this to see what ideas & thoughts are triggered.
    • No – OK, you’re part of the more normal population (for now) read on for some ideas. You might not need to cover all of the following (and if you do, it might slow you down)

Still reading? – Good!

The following apply to pretty much any change or investment program but answering them is surprisingly hard. Your context will probably differ to mine so I’ve not given all the answers today.

  • What are the top 1-3 benefits of pursuing this?
  • What are the top 1-3 costs of pursuing this?
  • Are there people outside the team that I’m going to need to “sell” to?
  • Are there people inside the team that I’ll need to sell to?
  • What are the risks, pitfalls and political or personal agendas?
  • What do we sacrifice – what’s the opportunity cost?
  • Who are my supporters and how can they help me?
  • Who’s on the fence, do they need to be involved and how can they help/hinder?
  • Who will fight against this and how big a problem is that really?
  • Do I ask for permission and support or press ahead and ask for forgiveness later?
  • Who will this impact and in what ways (positive and negative)?  **detail below

**How about those stakeholders?

For the set of stakeholder questions I suggest you’ll achieve better flow and find natural breaks if you cover positive and negative aspects for each role by “switching hats” as you work through rather than batching up all the positives first.

  • What’s in it for you and what’s the down side?
  • What’s in it for your peers and what’s the down side?
  • What’s in it for your boss and what’s the down side?
  • What’s in it for your team and what’s the down side?
  • What’s in it for your business and what’s the down side?
  • What’s in it for your users and what’s the down side?
  • What’s in it for your customers and what’s the down side?
  • What’s in it for a product manager/owner and what’s the down side?
  • What’s in it for a project/program manager and what’s the down side?
  • What’s in it for an individual team member and what’s the down side?

Wow! that’s a lot of questions.

As I said – you might not need to answer all of these and you really don’t want to have to write them all down but it’s worth spending a few minutes or hours considering these if you’re planning to invest your time, effort and credibility in something you believe in.

Beyond everything here, I also recommend a read of Fearless Change to help you on your way.

Readiness to Serve

Reading time ~ < 1 minutes

A couple of years ago a friend said: (I’m paraphrasing here)

My team are paid a huge pile of money to do nothing most of the time.

As an analysis team for a financial institution their goal was to be immediately available at the first sign of an anomaly in the system. Like every other good analysis team in the city, their goal was to identify and find a means of exploiting the next new anomaly before anyone else in the world did. When the rest of the world catches up, their edge is lost – until the next time.

Many times I see organizations saving pennies on billions of dollars of revenue to ensure they keep their teams “busy” or “fully utilized”.

  • If your teams are always busy, how will they be able to cope with the next bump in the road?
  • If your teams are always busy, how will they be able to stop and see the big picture?
  • If your teams are always busy, when will they have enough time to stop and sharpen their tools?
  • If your teams are always busy, who is looking around to see what the rest of the world is doing?
  • If your teams are always busy, who will you have available to exploit the next change in the market before your competition?

Unless money really is that tight, staff up your teams or balance your investment portfolio not just to deliver your current needs but also provide sufficient capacity to be “ready to serve” when the next anomaly hits your market.

Software Is Just A Means To An End

Reading time ~ < 1 minutes

Last year Chris Matts wrote an insightful post reflecting on the Agile Manifesto and business analysis. At the time it sparked some creative thinking but I didn’t turn it onto the right words.

Now I have them.

Writing software is just a means to an end. Our customers and users don’t always want software (with the exception of games). They want to be able to achieve something and fulfil their role.

Software was developed to help us achieve things in more effective, efficient, accurate ways. We have CAD tools because it’s seen as better than traditional draughtsmanship. We have Financials applications because it adds more value than traditional double-entry book-keeping. Software is written for commercial fighter aircraft because we made them too complicated for people to fly alone.

I could go on…

Remember you’re solving someone else’s problem or making someone’s life easier or safer, not just writing software for the sake of software.

The next time you think about adding a speculative “neat” feature or idea to the backlog, think about who will actually get value from it.

Admittedly, sometimes it might just be to tick the box on an RFP in which case your investment should be lower than if you’re delivering for real end user value but there is business value in doing something.

Learning to Say “No”

Reading time ~ 2 minutes

The great thing about working with software development teams is that on the whole they’re a nice bunch of people who just want to get on and do the right thing.

The tricky thing in large-scale enterprise product development is that there’s often aggressive targets pushed through sales & marketing onto product managers.

A common response is to take a shotgun to the enhancement request backlog and ask for everything from the development teams and negotiate down from that point.

Craig Larman & Bas Vodde summarized this brilliantly using game theory in the second of their scaling agility books as the “your fault” game.

Assuming like many large companies you’re faced with the challenge of an annual commitment-based project/backlog and you’ve whittled that down to the best you can do; chances are your product manager will come back at some point through the year having visited a customer or partner and, like Columbo, ask for “just one more thing”.

Agile development is meant to give us the flexibility to do this right?

The typical nice guy response is “well… it’s going to hurt … but we’ll try”…

Great! When your team gets kicked around the room at the end of the year for failing to meet their release commitments, I’m pretty sure I know whose “fault” it’ll be.


So… Time to dig yourselves out of that abusive relationship, get a backbone and learn to say “No”.

OK. Maybe that’s a bit harsh. How about…

“Sure we’d absolutely love to do that but here’s everything we’ve already committed to for you. What would you like us to drop first?”

That still sounds pretty collaborative – but now it’s on your terms.

You’ve also just highlighted that being Agile doesn’t mean not making commitments if that’s what your business needs, it means managing your customers better.

If the previous “we’ll try” conversation is the norm for your teams, chances are this is the first time your product manager has ever been put in this situation. Don’t expect it to be pretty or easy. You’ll need to stand your ground and limit the options available.

I’m a fan of visual management so here’s my take.

  1. Take all the features you’ve committed to already and put them on cards or stickies.
  2. Draw a box around them so that there’s no room for anything else.
  3. Bring your product manager to the table, hand them the new feature or item they want on a card of similar size to an equivalent feature.
  4. Ask them to trade out something so that the card fits.
  5. Once the trade-out decision is made. Confirm any timing impact on the other features.
  6. Optional… (but recommended If you’re in a low-trust environment) Get the decision in writing recorded in whatever your system of record is.

If you can’t get your product manager in the room, do the same thing with excel and coloured blocks representing each feature in a pipeline. Adding a new feature in anywhere in that pipeline extends the end date. If you’re on a fixed-date commitment that means something falls off the end.


Give this a try or adapt something similar for your own needs.

Creative Freedom & Product Ownership

Reading time ~ 2 minutes

After nearly 2 years of blogging internally for my employer and building up an internal online community readership of nearly a thousand subscribers, I’ve been looking forward to getting my voice to the outside world. I have a lot to say, opinions on most things in the software industry and enjoy sharing.

Having made the personal commitment and investment to do so, I find that 2 days later the words are all there but can’t find form. Where’s all the inspiration that caused me to do this gone?

I know my intended audience, I know the sort of things I usually write about are interesting, I have complete creative control and no real constraints on what I can and can’t say for the first time in years! What happened?

Complete creative control with no constraints?… Oh!…

Complete creative control makes life harder, not easier!

When you move to an environment where you are both delivery team and product owner, how do you go about putting some of the safety rails back up to get back on track and delivering successfully?

Whilst over in the US last week I saw a biography on “Pink” –  I’ve just learned a great lesson from her experiences.

Creative control for Pink’s first album was governed by her record company and whilst very successful, she sought a greater say in her future output.

For her second album, Pink contacted an artist she greatly admired and against the wishes of her record company, developed an album of new material on her own terms. In developing the album she had a clear goal and vision; pair up with a personal heroine, take control and prove she could deliver.  Pink broke the rules and had something to fight for.

On hearing the output, record bosses conceded she’s achieved something special and the album was a massive global success. Following its success her songwriting partner saw a huge surge in demand for her skills and Pink was given complete creative freedom and trust for her next album. – She’d massively over-achieved her goal.

Album#3 didn’t go so well. Her partner was no longer available, complete control was hers but there was no focus. Development was a strained, long process and whilst it did eventually ship, sales performance was generally poor.

Does this sound familiar?

Needless to say Pink’s output did recover.  Now I’ve found my voice I need to re-check both my original vision and my constraints.

After mentioning that I was about to write this post, a good friend and colleague sent me a link to this old business week article from the VP of Google’s search products. It frames the whole constraint thing better than I can – well worth a read.