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.

Spring in our nation’s capitol

Next week will be our second public viewing of our new MLS platform, Spring. The first seems like years ago in Anaheim at NAR 2011. Back then, we debuted Spring on iPads and PCs in our newly redesigned booth and turned quite a few heads on concept alone. A mobile-focused MLS platform? Not a retro fit of an existing code base? What kind of company puts all its chips on the table in a struggling market to start completely fresh on a completely new medium? Well, we do. Damn the torpedoes.

So what will you see in Washington next week? You’ll see the same booth with two iPads and two PCs demonstrating Spring, which has grown from infant stage to full on adolescence. I’ll hold my description of any details and simply ask, as a friend and business partner, that you come by the booth at some point and enter with an open mind.

This is not the MLS as you know it and it’s not meant to be. Come hungry for innovation and be prepared to leave your assumptions about where this industry is headed on the floor just outside booth #504. I’ve said it before and I don’t want to over-dramatize, but we’re doing something really important here.

Come see, discuss, add your opinion and hear ours. Booth 504. Right up front.

Safe travels.

Spring’s personality

Yesterday, I participated in one of the coolest things I’ve ever done here at Solid Earth. Well, the first time I flew an office helicopter was pretty awesome. Let’s just say I did the coolest thing I’ve ever done here in the office while sitting.

Here’s what we did.

A few weeks ago, our newest development hire, Adam Campbell, sent several of us a document titled, “Spring Design Persona”. It was a few pages worth of questions designed to get our thoughts about what the “personality” of Spring, our new MLS platform, should be.

That’s right. Spring’s personality. Have you ever considered that software might have a personality? It certainly does. Consider what Hotmail’s persona might be. Or iTunes or Angry Birds. What would Microsoft Word’s persona be? In other words, if MS Word were a human, what might that human be like? Look like? Talk like? What are their values, character, strengths and weaknesses?

For some reason I keep thinking of Mr. MS Word as Bill Gates. Why? Word is pretty utilitarian. No frills, just straight-forward click and type, edit, print, etc. I bet my MS Word user experience mirrors sitting in Mr. Gate’s office. No frills. Effective but, yeah.

That’s a persona.

Spring will certainly have a persona as well.

Our meeting where Adam reviewed and displayed our various answers was at first hilarious and then very, very interesting. Some of us envisioned that Spring is male. Others female. Words used to describe Spring were things like “intelligent” but “not condescending” or “beautiful” but not “self-absorbed”. It was totally fascinating to hear a group of people so involved in creating a product describe it using human characteristics. Very cool and thought-provoking.

So we’re taking these results and putting them into practice. Adam, who is in charge of the UI and UX (user interface and user experience) will digest all this data we provided and design accordingly. That sounds like a big job, but when you know that Spring is cool and hip, into new technology, but you can talk to him/her without feeling ignorant, it helps you make informed design decisions.

Do me a favor. Take a second and consider what the persona might be of your organization. If your MLS or brokerage was a person, what would they be like? How old are they? Male or female? Are they stern and serious or fun and outgoing? Do they act carefully and thoughtfully? Random and risky? Big spenders or cheap? Are they accessible or stand-offish?

With the Spring persona, we even got down to education level, body art and favorite pets. It may sound crazy, but to know the persona of your product is to know its direction. I will be able to sell the concept of Spring much better when I know (and like and respect) the person I’ve made her (mine was a her) to be.

So, try this yourself.

What kind of person is your organization.  Be very honest. Do you like that person? Would you want to work with them?

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.