The Apple Lisa was launched in January 1983, before the Mac. The launch wasn’t public, though. It was overshadowed by the Mac the following year.
The Lisa was named after Steve Jobs’ daughter. It was a massive investment for Apple. The development took five years.
The base Lisa in 1983 would cost almost $30,000 today. It had superior graphics. But it wasn’t as fast as the IBM PC. The graphics consumed the higher processing power.
Apple created a 100-person sales team. They were paid on commission. But they struggled to get companies to buy.
By September, Apple realized they’d likely only sell 6,400 Lisas. Not the nearly 11,000 they could build.
The Lisa failed due to poor stakeholder engagement. This caused several issues:
- Infighting among leaders led to turnover. The lack of cohesion meant no direction.
- A 1982 reorganization removed Jobs’ influence. John Couch then managed Lisa.
- Jobs moved to the Macintosh instead. His lack of influence on Lisa meant no vision.
The Stakeholder Engagement Problem
This happens a lot with tech teams. It doesn’t matter if you’re building a revolutionary personal computer, custom software, a no-code solution with some low-code UI, or researching and picking an off-the-shelf SaaS product.
The problem is the same — stakeholders don’t know exactly what they want. But they know immediately what they don’t like when they see it.
The reason is simple. Stakeholders don’t have time to attend all meetings or read all discussions about the work. They have minimal focus.
After all, your day is packed if you’re a CEO or run a small business. Meetings, calls, emails, decisions — you’re constantly multi-tasking and delegating.
This lack of stakeholder involvement causes issues. Engineers often ignore input and fail to adapt to feedback. This lowers product value.
Stakeholders don’t understand engineering inertia. Their early feedback would make engineering work more efficient.
But, stakeholders and engineers need to pay more attention to this problem. Engineers think they know better. Stakeholders don’t realize how much their involvement matters.
Why Requirements Documents Fail
“Okay, so the solution is always wrong. Let’s write down requirements and get stakeholder signoff.”
That’s what most technical managers think after negative feedback.
“Tell me what you want. I’ll build it. Don’t say I did it wrong later.”
I’ve been on both sides here. As an engineer, I tried holding startup founders accountable. As a CTO now, I’m the stakeholder seeing things I don’t like.
I’m tempted to try this approach of detailed requirements. I’ve tried it many times.
But it doesn’t work.
The main reason is that stakeholders like myself, clients, and end users have yet to learn what we want. We know what’s wrong when we see it. But we can’t specify the details. It’s a discovery process.
We need to find the solution together through iteration and creativity.
The Solution
The only solution is continuous stakeholder engagement. Have a plan to involve decision-makers throughout the process. Listen and adapt their input and feedback.
Agile approaches help, though engineers may dislike rebuilding things. Sprints produce tangible artifacts — mockups, prototypes, test versions.
Show these to executives early for feedback. Yes, pivots may be needed based on feedback. But changes are much easier at the prototype stage.
People are more likely to engage with something tangible, like a prototype. Talking for an hour or reading long docs inevitably loses focus.
Managing focus is critical with stakeholders. Illustrate context with visuals when asking questions. Record screencasts to showcase flows built in no-code tools.
Treat each other with respect. Engineers strive to build great products. Stakeholders do their best despite constant context switching.
Make their lives easier instead of just getting signoff. Understanding their lack of focus is hard. Ease the pain of constant meetings and delegation.
Originally published on Medium.com