Succeeding with Unfinished and Imperfect Solutions
Successful Unfinished Products
A Vice-President of Products at a software company once said:
A product is never finished nor perfect.
While “never” sounds strong, it makes sense. Microsoft Windows, widely used over three decades, remains unfinished. Microsoft recently released Windows 11. Who wants to guess when Salesforce will “finish” its products?
Unfinished products like Windows and Salesforce succeed because they constantly adapt to business and other needs. Requirements change as businesses evolve and demand more from software solutions. Security threats require software updates to keep data safe. Other quality attributes such as reliability, performance, and scalability require changes.
Managing Ongoing Change
A new software project can have hundreds of requirements, with discovery creating them faster than a development team can fulfill them. This stream of requirements leads them to believe they’ll never finish the software, and they’re right. So how do the project stakeholders start down the path to success?
A business analyst and a stakeholder like a product owner rank the requirements according to business value, urgency, and dependencies. Then, they send the top-ranked requirements to the development team to build a prototype or minimum viable product. Next, stakeholders review the prototype and provide feedback. Finally, they adjust requirements ranking or add new requirements.
The business analyst and primary business stakeholder keep grouping the remaining ranked requirements into versions. While they may change rankings, they avoid scope creep - introducing new requirements into a version under development. While the development team may never finish the software, they will always finish a version.
Add Imperfection as Needed
In some cases, a version cannot completely fulfill a requirement. For example, a Sales department wants to assign leads to representatives automatically but hasn’t worked out all the assignment criteria. So they start by assigning leads to territory managers, who assign them to representatives as a stopgap solution. Of course, sales management realizes it’s not the perfect solution, but it buys them time to determine how “perfect” automated representative assignments will work.
Also, a requirement could take too much effort to fit into one version. The business analyst, development team, and affected stakeholders split the requirement across multiple versions. For example, the first version automates straightforward steps in a process. The affected stakeholders agree this works well enough while the development team continues automating additional steps. It could take several versions to fulfill the split requirements.
Continuous Improvement, Approaching Perfection
Suppose Marc Benioff took the stage at Dreamforce and announced that Salesforce products are perfect and therefore finished. How would the crowd react after their laughter subsides? They would direct him to Salesforce’s IdeaExchange, listing thousands of customer issues where Salesforce doesn’t fit their needs.
A software solution never fits all needs perfectly, making requirements ranking indispensable. The business analyst and key stakeholder(s) rank the requirements, then package the most valuable ones into a version. If the development team determines the version exceeds time and cost constraints, the stakeholders face difficult decisions to remove requirements or split large ones across several versions. It’s better to finish an imperfect version rather than keep stakeholders waiting for perfection - which could take forever.
Demand for automation keeps software unfinished, with developers striving toward perfection in fulfilling requirements.