Old Features Made New

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.

Spring and Stakeholders

Over the past few months, we’ve been asking for our customers’ participation in gathering a crack team of individuals to start using a pre-release version of Spring. They will not be called the A-Team, but will simply be known as Stakeholders.

What is a stakeholder? A common term within the world of product development, “stakeholder” typically refers to key participants in the idea, development, and production phases of a product’s lifecycle. These individuals could be financial backers, project managers, target audiences, or other players.

At Solid Earth, we are purposefully using the term “stakeholder” when inviting people to use Spring during the development/pre-release stage because we want there to be an understanding that these people are more than just “testers”. In fact, we feel that the less we use the word “testing” the better; the objective for the interaction between our internal team and external stakeholders is to facilitate understanding.

The Objectives of Understanding

There are three specific things we’re trying to do as we invite external individuals into this stage:

  1. We want to learn about our users: behaviors, patterns, environments, values, strategies, etc.
  2. We want to listen to our users… praises, concerns, questions, comments, likes, dislikes, etc.
  3. We want to tell our users’ stories… processes, habits, objectives, goals, obstacles, etc.

By learning and listening to our stakeholders as they are introduced to Spring, begin to interact with it, discover useful or cool or painful or confusing points, and then reflect on what it means to them, we can begin to reciprocate and tell their story. We reiterate our designs and feature sets to better reflect what our most important partners, our users, are trying to attain.

So, being a stakeholder is much, much more than just testing and filling out the response form. Testing is simply an inherent by-product of the actually usage of the product. We’re excited that instead of performing trial-and-error tasks, stakeholders are implicitly and explicitly helping mold Spring into its ultimate form.

Track with us as we being to report on some of the trends and analytics we discover as our stakeholders engage with Spring.

Responding to people, places, and things

In the last post, you can watch me on video attempting to capture some of what we’re working on here at Solid Earth in our latest product, Spring.

I used a lot of words and ideas  about data, usability, and platforms, that maybe just flowed together; however, each of these concepts have a real, profound meaning to our work on Spring. What we’re working towards is a cohesive, intuitive, and beautiful way for both real estate professionals and the general public to navigate through listings and real estate information.

I say navigating, because that’s what it really is.

There is a lot of information surrounding real estate – from the details of individual property listings to regional demographic and landmark data to the profiles of brokers and other participants – and, historically, it has been a true challenge to relevantly expose this data in the right way, to the right person, at the right time. Searching has evolved into a Don Quixote-esque pursuit of potential information, with elaborate forms, intricate query combinations, and possibly even MIT-level trigonometry (if you want to do a radius search). Comparing data becomes a second layer of complexity, sharing data in a sensible way yet another level… and so on. It’s a routine where only experience in wrangling the data can truly help you.

Navigating is always easier with a Wookiee.

The center of this scenario lies in the fact that we must also be stationed our desktop or laptop in order to embark on these voyages of discovery. Want to perform a search? Go to the office! Want to see some sensible data analysis? Print it out! Want to share your results? Paste into an email! Want to check out a listing while you’re at a spontaneous coffee shop meeting with a customer? Pull it up on your iP… um… no wait, don’t do that. Want to sit on the couch at night and see the day’s analytics? Your tabl… nevermind, not that either.

A recent survey looked at where people used their smartphones and found 84% use them at home, 74% use them in line or waiting for appointments, 64% at work, and 47% during their daily commute.

Compete Plus, March 10 2012

It doesn’t need to be this way.

In fact, we believe that it can’t be this way, not anymore. Now, our day-to-day routine consists of moments that require access to information spontaneously, because it is expected of us. People want you to share that information with them, and they hope that when it arrives at their digital door that it will be packaged and dressed nicely.

Spring is being built with this explicitly in mind, for now, and for the future. It’s easy enough to build for the select number of screen-equipped devices we typically use today (think mobile devices, tablets, laptops and desktops), but what about a year or two from now? Five years? You may be looking up the history of your home on your refrigerator, for all we know. And so, we’re creating with that flexibility, or responsiveness, in mind as well.

As we continue to build Spring we are excited to share the things we’re doing and discovering along the way. This post is just a rough intro to bits of the strategy we’re employing as we create, so please stick close as we move forward. There’s some great stuff just over the horizon.