Agile won the war but lost the peace

iStock-856693018Medium-2018-11-8-16-53.jpg

“I’ve spoken of the shining city all my political life, … in my mind it was a tall, proud city built on rocks stronger than oceans, wind-swept, God-blessed, and teeming with people of all kinds living in harmony and peace; a city with free ports that hummed with commerce and creativity. And if there had to be city walls, the walls had doors and the doors were open to anyone with the will and the heart to get here. That’s how I saw it, and see it still” President Ronald Reagan, Farewell to the Nation, January 11, 1989

Back in 2001 when the word agile appeared it was a manifesto – a set of ideas, the term “agile” also served to group a bunch of tools and techniques which could make software development “better.” More importantly to my mind, it painted a picture of a shining city on a hill we all wanted to live in.

Agile was a place you wanted to go, it was a journey you wanted to make, it offered hope. More important as the tools – sprints, stand-ups, etc. – and approaches – just in time, last responsible moment, test first – were the stories agile people – including myself – told. These were stories of a better world, of that shining city on the hill.

And not unimportantly, in a world of search engines “agile” gave you something to search for. Before agile you could search “make my software development team better” or “software development process improvement” but what you got was a very mixed offering. AltaVista (and the young Google) would suggest links for CMMI, or ISO-9000, or vendor tools to “fix it”, or proper design, or… there was no coherent message. Most of these ideas resolved around senior people making big decisions and then imposing them.

Then along came agile: it offered to involve everyone, everyone made decisions, everyone was happy and we could all go to that shining city on a hill – more than that, we all had an important part to play in building that city.

Today everyone is agile. Nobody is promoting traditional (“waterfall”) working, CMMI, PMI and everyone else has incorporated agile (to some degree). Not being agile is about as popular as leprosy.

But very few of us have reached the shining city on the hill.

Along the way agile has been watered down, in becoming compatible with everything else it is less different, it is less attractive, fewer workers are motivated to take the journey. And as “the powers that be” have found ways to bring control-and-command back to teams (maybe in the name of scaling) fewer people are invited to help build the city.

Ironically, as we (the agile community) has made agile management friendly we have made it less worker friendly. Today senior managers “get agile” and want their organisations to be agile. But those at the code face seem to have less and less motivation. And those in the middle… sometimes they seem to want to change just enough to declare success but no so much that things really change.

For some people agile has become completely discredited – I wrote Why do Dev’s hate agile? last year and I’m presenting it in London next week. Agile isn’t a shining city on a hill, agile is trench warfare.

And Googling “agile” presents a long long list of links with less and less coherence.

Agile won the war. Agile is respectable and everyone is agile now. Big business rush to be agile, Governments want to be agile, blue-chip consultancies will sell you agile.

But agile lost the peace.

While many say they are agile, few software developers live in a shiny city. The place they live in might be better than the place they came from but it doesn’t live up to the dream many of us shared 15 years ago. Agile has become an excuse for failure and a thing to be imposed.

The thing that passes for “agile” today is too often a watered down version of the original dream. Worse still, we don’t have a word to describe that shining city we all want to get to. Russians have an expression for this:

“We wanted the best, it turned out like always.” Viktor Stepanovich Chernomyrdin, Prime Minister Russia, 1998-1999

Me? – I still dream of that shining city on the hill, I still believe agile is the right way to get there, I still wave the flag for agile but more and more I feel the need to explain myself and tell people that the agile I dream of is not the agile they may experience.


Receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Continuous Digital published – done?

CDpile2cut-2018-10-9-14-43.jpg

Continuous Digital is done.

Probably. Maybe. Definitely maybe.

Continuous Digital is the second of my two #NoProjects books. Many people ask: “why two?” “What is the difference between them?” “Do I need to read both?”

Short answer: Project Myopia explains why the project model is bad for software development. Continuous Digital describes what to do instead.

Long answer: as the #NoProjects hypothesis grew, as I thought about it more, as I talked to others about the ideas – specifically Steve Smith, Joshua Arnold and Evan Leybourn – the ideas grew. My thinking both on “what to do instead of project management” and “why do something different” grew.

Specifically I saw that the combination of Continual Delivery and Digital Business meant there was a stand alone case for moving beyond the project model. Whether you agree with the problems I discuss in Project Myopia or not there is a case for changing the way businesses are managed.

That is why I split the too books. Project Myopia is a companion book, it is not a prequel, a sequel, a book one or a book two. It is a book some people will read in its own right.

Continuous Digital argues that since business are increasingly digital, and as businesses strive to survive and grow then technology development is not a separate “project” it is inherent to the business. Technology and innovation are business as usual.

Stopping, even pausing, work – as in the project model – surrenders competitive advantage and introduces extra costs (time, money, risk). What is needed is a new model. A continuous model.

Continuous Digital is now published on Amazon in digital form and will soon be there – and in other booksellers – in physical form. (If you can’t wait for a print copy you can buy one from Lulu where they are slightly cheaper too.)

So I’d like to say Continuous Digital is done. But…

Even before I saw the final print version I had requests for an audio version of both Project Myopia and Continuous Digital. I’m debating whether to do these, if you would buy an audio version please let me know, if enough people want it I’ll do it.

Second, once I saw and held the final, done, version in print new ideas came to me. I don’t want to revisit the text – although I might fix a couple of typos – but Continuous Digital is a big book, 350 pages. And I know many people will be put off by the size.

So I’m thinking of turning it into four smaller books, each around 100 pages in length and each corresponding to one part of Continuous Digital. Maybe.

It is never done. It is continual.

#NoProjects: Project Myopia is published

ProjectMyopiaNew-2018-09-10-11-17-1.jpg

Project Myopia – the original case for #NoProjects – has been a long time in the works but it is now done. Published. For sale on Amazon.

Projects fail. Some say 40% of all IT projects fail, some say 70%. And it has been that way for years. Each project fails for its own reasons but they all share one thing in common: the Project Model. Could it be the project model itself which creates failure?

Projects end. Successful software continues. Twenty-first century digital businesses want to continue and grow.

Project Myopia is available to buy on Amazon today – the physical version should joined the eBook in a few days.

Project Myopia gives the case against projects – the hard core #NoProjects arguments. A second book, Continuous Digital will join Project Myopia in a few weeks on Amazon. Right now copyediting isn’t finished on Continuous Digital, plus the physical copy needs to be worked out. In the meantime late drafts of Continuous Digital are available on LeanPub.

Release or be damned

iStock-166161352small-2018-09-6-12-26.jpg

Back when I was still paid to code I had a simple question I posed to troubled development efforts:

“Why can’t we release tomorrow?”

This short simple question turns out to be amazingly powerful. I remember one effort I was involved with in California where a new CEO took over and started cutting jobs. I posed this question to the team and in a week or two we did a “beta release” – we did those sort of things back then. Asking this question was the key that allows us to question everything, to cut the feature list – or rather push work back, it stayed on the to-do list but we didn’t let it stop us from pushing to release.

We rethought what we were trying to achieve: we didn’t need the whole product, we just needed enough of the product to work to show to one specific target customer. Even if they signed there and then we had weeks before they used it in anger. But until we released something, until we had something “done” our team, our product, look like just another “maybe.” We had to draw a line under it so the new CEO wouldn’t draw a line under us.

Saying “only do the essential” is easy and come up again and again, whether it is Minimal Viable Product, Minimal Subset, Must haves in Moscow rules, but it is far easier said than done. One persons “essential” is so often another persons “optional extra.” In this context, when I say “essential” I mean “the parts needed to make the system work end to end” – I’m far closer to the old walking skeleton idea.

I was reminded of this question by a couple of endeavours that came to my attention during the summer. Well, I say came to my attention, I feel a bit responsible. Both endeavours are happening at clients; clients who I had fallen out of touch with. My style of working is to help clients who want help, I don’t like selling myself. These clients didn’t ask for more help so I didn’t jam my foot in the door, in retrospect maybe I should have.

In one case the team were doing very well. They were iterating, they were TDD/BDD’ing, they were demoing, they were working with the client, they were doing everything … except releasing. Then one day the client asked “when will it be done?”

Now think for a moment: What if you could release your product tomorrow?

The thing is, without actual products those around the team look for signs that the team can be trusted, that they team will deliver, that the team are thinking about what is to be done. People ask for proxy-products: plans, schedules, risk-logs, budget forecasts and so on. When stakeholders can’t see progress they look for things to assure them that there is (or will be) progress (soon).

Who needs plans and predictions about the future when the future is here tomorrow?

Actual releases are they key to reaching the new world, they change everything.

So I feel guilty: I should have inflicted myself on these teams, I should have been there again and again bugging them “Go to release”, “Remove that barrier”, “Force it through”.

Being able to ship an update of your product has a transformative effect.

It demonstrates the team have the ability to do the job in hand.
It demonstrates you have quality. It obliterates the need for a test-fix-test-fix aka stabilisation aka hardening phase.
It blows away sunk costs because something has been delivered.
It removes “maybe” and “ready but…”
It is probably the greatest risk mitigation strategy possible.
It creates trust and provides a platform for solid conversations.

Most of all, a released product is a far better statement of progress than any number of plans or forecasts.

This does not mean everything is done. Sure there are things left undone but there will be things left undone when I’m on my deathbed, that is the nature of life. As much as we (especially men) love to collect entire sets there are few prizes in life for completing everything on your bucket list.

Having a released product utterly changes the nature of the conversation. Conversations are no longer full of “ifs” “maybes” “shoulds” “how long will it take?” “what are the quick wins?”. Those questions can go away. In its place you can have serious conversations about prioritisation and “what do you want tomorrow?”

This is all part of the reason I love continuous delivery. Teams can focus on real priorities and stop wasting time on conjecture.

In my book if you don’t have a releasable product at least every two weeks – say every second Thursday – you are not Agile. And if you haven’t released a product to live in the last two weeks you are probably not Agile.

I don’t care how close you get to a releasable product: it isn’t a release if it isn’t released to a live environment – close but no cigar as they say. (OK, I’ll accept the live environment may not be publicly know, or might be called a beta, but it has to be the real thing.)

Nor should you rest on your laurels once you have regular releases (to live) every second week. That is but first base. You have opened the door, now go further. There are at least 13 opportunities to improve.

If you cannot do that now then ask yourself: Why can’t we release tomorrow?

And start working to remove those obstacles:

  • Reduce the number of work items you are aiming to put in the release.
  • Fix show-stopper defects now.
  • Running tests now.
  • Get those people who need to sign-off to sign-off.

Software development has diseconomies of scale: many small is cheaper than few large.

And once you have your release you can turn your attention to making sure these things don’t happen again:

  • Reduce the amount of work you accept into development at one time.
  • Fix every defects as soon as they are found.
  • Automate tests so they can run more often. (Automate anything that moves, and if it doesn’t move, automate it in case.)
  • Find a way to reduce the time it takes to get sign-offs: remove the sign-off, make sure the signer prioritises signing or delegate someone else to sign (or automate the signature.)

If there are essential processes, activities, third-parties (or anything else) that has limited bandwidth which need to be done before release but inject delay then re-orientate your process around that bottleneck. For example, if your code needs to pass a security audit before release (an audit you can’t automate that is) then, downsize all the other activities so that the audit process is 100% utilised. (OK, 100% is wrong, 76% might be better, but thats a long conversation about queuing theory.)

Again and again I seem condemned to learn the lesson: nothing counts but working software which is used.

As for my team, and my job in California, it didn’t save me. I regret not asking the question sooner.

Agile is the process digital technology needs

1200px-Workers_in_the_fuse_factory_Woolwich_Arsenal_Flickr_4615367952_d40a18ec24_o-2018-07-18-12-19.jpg

In my presentation at Agile on the Beach last week I continued my discussion of Agile and Digital. It is increasingly clear that digital and agile are intrinsically linked. Specifically, business need agile processes to get the most out of digital technology. My “Agile, Digital & the new management paradigms” presentation is online but let me give you the argument here.

There is a long standing model of technology change – so widespread I can’t find the original source – which says change comes in three steps:

  1. First new technology allows the same processes and activities to be done better, faster, cheaper, more efficiently. In this stage new technology is used to do the same things, the processes and practices change little.
  2. Next new technology allows process and practices to be reconsidered and changed to make the most of new technology. Work becomes even better – whether that be faster, cheaper, higher efficiency, superior products, whatever.
  3. Finally new innovations appear because of the technology and new processes. One can see opportunities for new businesses, new business models, the next round of technology innovation and more.

So the whole thing repeats.

Look at the photo above. According to WikiCommons this is a picture of a factory at Woolwich Arsenal sometime in the 1800s. Notice the belts stretching from the ceiling to the workstations. These carried power, or to be more precise motion. Above the workers is the line shaft which turns. The shaft is driven by a central power (motion) source somewhere, probably a water wheel or a steam engine.

This is before electricity. The line shaft and the belts carry the power the factory needs to work. And they break, the longer they are the more prone to breaking they are. Factory design is constrained by the need to have straight lines for the line shaft and short distances between the shaft and the workstation. And factory design dictates layout and processes.

Then came electricity.

Electricity allowed each workstation to have its own motion generator. At first factory owners used electricity to do the same things faster and more reliably. They could dispense with the steam engine and thus the stokers and coal it needed. But at first they didn’t seize all the advantages electricity brought.

It took time to understand how a factory could be laid out more efficiently and how processes could be changed. When they did factories got even more efficient and faster. Some might argue that it took the coming of Lean manufacturing to complete these process changes.

The same story has played out in industry after industry with technology after technology. Think of Word processors: first they helped secretaries do their job faster, then processes changed and everyone wrote themselves, goodbye secretaries. Containerisation in the shipping industry is another. First ships loaded and unloaded faster. Then the shipping companies innovated but more importantly world trade innovated. Some observers claim containerisation was a more significant factor in trade globalisation than free-trade agreements.

Digital technology is like electricity. It changes business, it creates new opportunities for doing things differently. To get the most from digital technology you need new processes. Right now most companies are stuck – even happy – doing things faster. Only when they change processes will they get the full benefits.

Agile processes are that change.

Agile ways of working help companies get more from digital technologies. Without Agile companies using digital technologies are just doing the same old thing faster.

Agile started in software development for two reasons. First software developers had a lot of problems, they had the need to change. Second, programmers had the first access to digital technologies.

Ray Tomlinson, a programmer, was the first person with e-mail. Tim Berners-Lee, a programmer, had the first web-browser. Ward Cunningham, a programmer, had the first Wiki. I could continue.

Software developers created Agile because they needed to and they could.

This is why Agile is taking off in marketing.

Outside of technology itself marketing has probably been more exposed to digital technology than any other part of business. First with digital publishing then with social media. At first digital helped marketing departments do the same work faster. Next it changed what you could do entirely. Marketing is adopting agile because those processes allow marketeers to do a better job when working with new digital technology.

So forget all those arguments about agile being a better way of working (it is but never mind).

Forget all those stories of agile like processes and practices before 1998 (yes they existed but that doesn’t change things).

Forget the debate about waterfall and upfront planning versus agile and just-in-time (that is history).

All you need to know is:

  1. Digital technology is helping you do things faster/better/cheaper.
  2. Agile ways of working allow you to get more from digital tools.
  3. More innovation is coming.

Agile is the process for digital businesses.

Sign-up to receive these posts by e-mail and free eBook of Xanpan

Image of Woolwich Arsenal factory taken from WikiCommons, no known copyright.

Organizational structure in the Digital and Agile age

iStock_000003002725XSmall-2018-07-3-18-18.jpg

Someone asked the other day: how should an organisation be designed?

There are two potential answers, which actually aren’t as contradictory as they look at first sight.

The first is very simple: Don’t.

That is, don’t design your organization, don’t set out an organizational chart, don’t set out a plan and aim to restructure your organization to that plan. Rather create the conditions to let a structure emerge.

I suppose its the difference between “design” meaning “create a plan for the way you want things to be” and “design” meaning “the way things are arranged.” To differentiate them the first might be called “intentional design” and the latter “emergent design.”

That does not necessarily imply all emergent structures are good. As we see in code sometimes emergent designs are not always the best and over time they need refactoring. Which implies at some point there needs to be intentional design.

Put it like this: I’d rather your organization pulls the design rather than you push a design on the organization.

Organizational structure is itself a function of business strategy. And both need to be part emergent and part intentional. Although you might have noticed I tend towards emergent while most of the world tends towards intentional!

Thus it helps to have a reference model of how you think the organization should be, maybe something to steer the organization towards.

So the second answer to the question would be longer:

  • Create standing delivery teams which are embedded in the business line itself. This is sometimes call stream teams, or stream based development, or “teams aligned to the value stream”, or several other names I can’t think of just now.
  • Each business line is itself a stream of work and digital delivery teams support that work.
  • Teams contain all the skills and authority to do the work that is required for that business stream.
  • The team is part of the stream so the business/technical divide should dissolve. Something I call BusTech.
  • Teams are value seeking and value creating: the team seeks opportunities to create value for the business and delivers on the most valuable ones.
  • Devolve authority to the teams whenever you can. Teams are mini-businesses. (Notice I deliberately don’t use the word empowerment.)
  • Teams grow when the business is successful and more digital capability is needed. And teams shrink when money is tight or less capability is needed.
  • Teams may split (Amoeba style) from time to time. New teams may be in the same business line (addressing another question) or part of another, possibly new, business line.
  • Active – or Agile – Portfolio Management sits on top to monitor progress, provide extra resources, remove resources, etc. There may even be multiple portfolio processes, one at the business line level and perhaps one above multiple business lines.
  • Minimally Viable Teams are started to explore new initiatives, sometimes these go on to be full standing teams but they may also be dissolved if the idea doesn’t validate.
  • Seek to minimise common services between teams because these create bottlenecks, conflicts and delays. Each team should stand alone. This may mean some duplication, and therefore some extra costs, but accept that. Once you have your model working you can fine tune such things later.
  • Don’t worry about planning and synchronisation between teams to much, worry more about getting the teams to release more often and deal with synchronisation issues when they become a problem.

They are the main points at any rate. If you’d like to know more Continuous Digital contains a longer discussion of the topic. (Continuous Digital actually builds on Xanpan in this regard, and the (never finished) Xanpan Appendix discusses the same idea.)

Sign-up to receive these posts by e-mail and free eBook of Xanpan

#NoProject #NoEstimates workshop

MilkCartons-2018-07-3-17-57.png

In August I’m running a 1-day workshop in Zurich with Vasco Duarte on the bleeding edge of Agile: #NoProjects and #NoEstimates for Digital First companies.

This is a pre-conference event for the ALE 2018 conference which is happening the same week in Zurich. Everyone is welcome, you don’t need to attend the conference.

If you book in the next two weeks you get it for cheap, after July 20 the price goes up – although its still only a few hundred euros.

Book now, save money and secure your place – places are limited!

For those ho can’t get to Zurich in August I’ve got a Continuous Digital workshop of my own and a half-day management briefing. Right now you can book either of these for private in-house delivery. I’m looking at offering these as public courses here in London, if you are interested get in touch and help me fix a date.

(I have a love hate relationship with #NoProjects, I’d love to retire the name but it resonates with so many people. So I tend to use #NoProjects when I’m discussing my critique of the project model and Continuous Digital when I’m setting out my preferred alternative.)

Best practices considered harmfull

NoBestPractice-2018-06-20-16-53.jpg

I’ve long worried about “Best Practices”. Sure I usually play along at the time but lurking in the back of my mind, waiting for a suitable opportunity are two questions:

  • Who decided this was best practice?
  • Who says this practice can’t be bettered?

I was once told by someone from the oil industry that it was common for contracts to specify “best practice” should be used. But seldom was the actual practice specified. Instead each party to the contract would interpret best practice as they wished, until something went wrong. At that point, after an accident, after money was lost they would go to court and a judge would decide what was best practice.

Sure practice X might be the best know way of doing things at the moment but how much better could it be? By declaring something “best practice” you can be self limiting and potentially preventing innovation.

Now a piece in MIT Sloan Management Review (Why Best Practices Often Fall Short, Jérôme Barthélemy, February 2018) adds to the debate and highlights a few more problems.

Just for openers, sometimes people mistakenly identify the practice creating the benefits. Apparently some people looked at Pixar animation and decided that having rest rooms (toilets to us English speakers) in the centre of an office floor enhances creativity. They might do, but there is so much else happening at Pixar that moving all the toilets in your organization will probably make no difference at all.

But it is worse than that.

Adopting best practice from elsewhere does not mean it will be best practice in your environment but adopting that “best practice” will be disruptive. Think of all the money you will need to spend relocating the toilets, all the people who will be upset by a desk move they don’t want, all the lost productivity while the work is going on.

The author suggests that in some cases that disruption costs are so high the “best practice” will never cover the costs of the change. Organizations are better shunning the best practice and carrying on as they are. (ERP anyone?)

It gets worse.

There is risk in those best practices. Risk that they will cost more, risk that they won’t be implemented correctly and risk that they will backfire. What was best practice at one organization might not be best practice in yours. (Which might imply you need even more change, even more disruption at even more cost.)

In fact, some best practices – like stock options for executives – can go horrendously wrong and induce behaviours you most definitely don’t want.

So what is a poor company to do?

Well, the author suggests something that does work: copying good practices. Not best but “just OK”. That works. Copy the mundane stuff, the proven stuff. The costs and risks of a big change are avoided. (This sounds a bit like In Search of Mediocracy.)

In my world that means you want to be getting better at doing Agile instead of trying to leapfrog Agile and move to DevOps in one bound.

The author also suggests that where your competitive advantage is concerned keep your cards close to your chest. Do thinks yourself. Work out what your best practice is, work out how you can improve yourself.

I’ve long argued that I want teams to learn and learn for themselves rather than have change done to them. But I also want teams to steal. When they see other teams – at home or elsewhere – doing good things they should steal practices. The important thing from my point of view is for the teams to decide for themselves.

Sign-up to receive these posts by e-mail and free eBook of Xanpan

Because your “competitors have it” IS NOT STRATEGY

iStock-514378725medium-2018-06-5-17-04.jpg

“We need a product that does X because our competitors have a product that does X”
“Our product needs feature Y because our competitors product has feature Y.”

It makes me want to cry.

Let me clear: building something because your competitors have it IS NOT A STRATEGY.

Neither is it a particularly good tactic.

Stop obsessing about your competitors and think about your customers.

I don’t doubt that your people are being told that customers are buying the competitor product because it has X or Y and I don’t doubt that some of your people feel that if you only matched the competitors feature for feature you would win but I just can’t see it myself.

For a start, is feature Y really the only thing loosing the sale? Are the products so well balanced that this one small thing is it? And is there really nothing that your product does better?

Try this simple experiment: tell the customer that feature Y will be delivered next month and see if they decide to buy yours there and then or find something else that makes the competition better.

Now lets suppose you decide to build Y. Before you make any plans ask yourself:

While you are building feature Y what are your competitors going to be doing?
Will they stand still or will they be adding feature Z?
And once they have feature Z will you need to play catch up?

Chances are that tomorrow you get to where you want to be (where your competitors are today) only to find your competitors have something else you don’t have either.

I’ll agree this is a good strategy if you have deliberately chosen to be a Fast Follower – you can play Android to your competitors iOS. Just make sure you know why your customers will choose your Android over the competitor iOS.

Will you be cheaper?
Or better?
Or will you bundle some other goodies with it?

Before you run to where your competitors are today ask yourself: where will your competitors be tomorrow?

If you still insist on building this feature you need to

  • Make sure you do a much better job (easier to use, more intuitive, faster to produce results, better quality results, or some such)
  • OR you need to do it fast and cheap so you can spend your precious resources on building something the competitor doesn’t have
  • OR you being overwhelming resources to the table so you are going to stand a chance. Every day you delay the competitor gets further ahead, so don’t try half measures

A better approach is to find out what your customers actually need. Stop looking at the features, go back to first principles: what is the problem your customers face? what is the job they are attempting to make progress with?

How can you help your customers with this job?
How can you make them faster?
How can you help them achieve their work more cheaply? Or at better quality? – in fact, what do “better” and “quality” look like to them.

Someone – I honestly forget who – told me earlier this year that they wanted to catch-up with their competitor and overtake them.

One small flaw there: if you build features to match your competitors you can never overtake them because you won’t know what to build once you reach parity.

Put it another way, you add all the features they have today, and all the features they add while you are catching up. What do you build next? Until they build their next version (and recapture the lead) you don’t know what to build. And if you build something different you just lost feature parity.

So, go back and examine what your customers are using your tool for. Look at the job to be done, look at how your customers are doing their job and using your tool and work out for yourself how you can help customers do a better job.

Celebrate the difference, explain why you are better.

And please forget about matching the competition.

I’m old enough to remember the days when WordStar was fighting WordPerfect, AmiPro was fighting them both, and all were better than Microsoft Word. Adverts and magazine reviews would compare them feature to feature. Someone somewhere thought people bought word processors based on the number of features.

Then Microsoft launched Windows and everybody went over to Microsoft Word for Windows almost overnight.

Don’t focus on your competitors. Focus on your customers. Unfortunately that requires more work and some original thinking.