Spring is not a new List-It.
It’s a completely different product.
We’ve said this many times before, and will probably have to keep saying it, but that’s ok. And it’s not simply an exercise to distance our new product from a legacy platform, but it’s recognizing that Spring is a departure from the seas Solid Earth has been sailing for the past 12+ years with List-It.
One of the ways this is most profoundly seen is in how we address feature development in Spring. Previously, the typical process for developing a feature began by with customer putting in a request for something new they wanted. They would have requirements, ideas, and objectives, and we would be sure to make note of all those as a feature list. The list would be then given to the development team who would discuss how they would build it and then dive into writing code.
However, there were some problems with this. Little or no use-cases would be considered outside of the customer’s initial checklist, so often the feature wouldn’t have any practical use beyond the customer’s immediate need. In fact, sometimes the completed feature would end up not meeting the customers requirements either, because the actual use of the feature wasn’t talked about. Also, because the people coding the feature were so disconnected from the customer asking for the feature information was lost and more detail couldn’t be sourced, and ultimately needs weren’t being met. Only through tedious iteration was something built that was of value.
The old way was reminiscent of the “Broken Telephone Effect”, as described by Martin Crisp:
…at each handoff of information the original content is altered. The resulting approach includes a lot of re-work and escalating project costs…
Now, we don’t ask “what?”, we ask “why?” and “how?”
With Spring, we’re changing the way that introduce and develop features through a more engaging process. While some of the features that ultimately end up in Spring may be familiar from List-It, it’s not a simple port over. Instead, we’ve taken each piece of the product and re-thought it from the ground up. Rather than simply finding out what the pain points are of a current feature (which we also did), we’ve talked to real estate professionals about how they do business on a day-to-day level and what tools they need to help be more effective. We want to know why they want features and tools and how they fit into their workflows.
Involved in these conversations are members of our sales and development teams, so we’re getting a cross-cut understanding of what customers are looking for. Then we take these needs and ideas, storyboard them, create paths, add usefulness and remove cruft. This allows us to produce functionality in Spring that we feel has a solid foundation in extensive real-life requirements and not an arcane, one-off need.
Our processes are actually really helpful and fun to participate in. Hopefully, our Stakeholders will also discover that participating in them is rewarding and produces solid results. After all, it’s our customers’ real needs and aspirations for success that drive our product.
For more insight on the transition from List-It to Spring, check out Matt Fowler’s latest blog post on Solid Earth’s website.