Strategy
Part of A productivity software strategy that measures the current route before proposing a better one
Naming the tool before the work, and six other productivity software strategy mistakes
Avoid seven productivity software strategy mistakes involving scope, evidence, roadmaps, channels, security, reviews and unsupported benefit claims.
These seven business productivity software strategy mistakes were chosen because each can break a planning decision before product performance is known. The list was compiled on 5 September 2026 from cited UK government, regulator and security guidance.
It covers organisations planning for England, with no vendor assessment and no detailed legal, tax or investment advice. The order is a workflow, not a ranking.
What to take away
- Start with the job to be done, not a tool category or feature list.
- National business counts are denominators, not evidence of reachable demand.
- Roadmaps should express intent and assumptions, not promise distant features.
- Implementation work and cloud security duties often sit with the customer.
- Usage metrics alone do not prove less effort or better work.
1. Naming the tool before describing the work
Starting with a category or feature list turns every interview into confirmation seeking. Reconstruct the job from trigger to completed result, covering people, records, delays and exceptions.
Government discovery guidance tells service teams to understand the problem and its constraints before committing to a solution. A commercial planner should keep problem evidence separate from interface preferences.
2. Treating a broad business count as reachable demand
National totals are useful denominators only when their coverage matches the question. ONS business activity and location data concerns VAT or PAYE registered enterprises and local units. It does not say which organisations share a workflow, can be contacted, hold budget or intend to change software. Define those steps independently.
3. Making the roadmap a promise of features
A distant feature calendar creates false certainty while concealing the decisions those features are meant to open up. GDS advises teams to build adaptable roadmaps around intent, priorities and ownership. Put the immediate evidence task in detail, keep later options broad and attach every commitment to an assumption.
4. Opening every channel at once
Simultaneous direct outreach, partnerships, content and framework bids can produce activity without comparable learning. Choose one primary route for a bounded period. Use the same eligibility rule, decision start, decision end, labour unit and observation window. Preserve refusals and stalled cases instead of reporting only meetings.
Where personal details support outreach, the ICO's business marketing guidance shows why subscriber type and personal-data use matter. Get the proposed process reviewed rather than relying on a generic B2B label.
5. Leaving implementation outside the offer
A subscription price does not reveal the work required to import records, configure permissions, train administrators or connect existing systems. If a partner performs those tasks, define who owns quality, customer communication and support. An apparently scalable proposition may actually depend on scarce specialist hours.
Before committing, run one representative setup from source record to accepted output and log each intervention. That rehearsal exposes work which a demonstration can easily hide.
6. Assuming the supplier owns all cloud security
The NCSC's guidance for using SaaS securely assigns important work to the customer side, including configuration, identities, data handling, monitoring and incident response. The precise split depends on the service and contract. Record it before a pilot, and test offboarding as well as setup.
7. Reporting movement as a productivity outcome
More accounts, sessions or automated actions may show use; they do not automatically show less effort, shorter elapsed time or better work. Define the baseline event, population, exclusions and data source before launch. Keep usage evidence apart from customer testimony, sales progress and accounting results.
End the review by choosing one correction with an owner and decision date. Fixing the highest-consequence assumption is more valuable than turning all seven headings into a decorative checklist.
Before you act
- Describe the current job from trigger to result.
- Check whether national totals match your question.
- Attach every roadmap commitment to an assumption.
- Run one primary outreach route for a bounded period.
- Rehearse one full setup from source record to output.
- Record the cloud security split before any pilot.
Common questions
Why is naming the tool before describing the work a problem?
Starting with a category or feature list turns every interview into a search for confirmation. The article says to reconstruct the current job from trigger to completed result, including people, records, delays and exceptions, and to keep evidence about the problem separate from interface preferences.
What do ONS business activity and location figures actually cover?
The article states that ONS business activity and location data concerns VAT or PAYE registered enterprises and local units. It does not say which organisations share a workflow, can be contacted, hold budget or intend to change software, so those steps must be defined independently.
Who owns cloud security when using a SaaS product?
The NCSC guidance cited assigns important work to the customer side, including configuration, identities, data handling, monitoring and incident response. The precise split depends on the service and contract, so the article says to record it before a pilot and test offboarding as well as setup.
