Bootstrapping better products

A significant series of events have happened since we started focusing from simple web sites to web products. Thanks to a remarkable case history and our link to the Talent Garden network we have met several entrepreneurs and companies willing to start digital startups in need of technical know-how in design and coding.

As complex as a simple site might be, it will very likely fall under the “well-known requirements” domain. It’s just fine to simply define upfront how you want your site to look and work in every detail. It’s no rocket science to agree on a scope, a budget and timing estimates.

A very different rule applies to digital products. The “site” is not just a showcase: it’s the product itself, its core business. We, as facilitators, try to boost the startup phase of a product with our know-how, understanding the business and contributing to its development plan.

Almost every startup today embraces the lean methodology:

set assumptions → validate them early through an MVP* → iterate.

*Minimumn Viable Product

The exact scope of a new digital product is mutable: requirements will change while designing and validating the assumptions directly with its users.

In this scenario, long requirement-specs are toxic; what needs to be intrinsically flexible to be successful would otherwise become rigid and formal [1].

This inevitably affects the client-vendor relationship too.

But then, how is it possible to help clients manage budget and schedule into lean cycles? How can we apply this to real situations?

Start with Why

As Simon Sinek would say, it is fundamental first to share why we spent our nights studying a better solution to the flawed client-vendor paradigm.

1. Reason #1 We like what we do, really. Our mission is not to change the world. We believe we can create a better place to work, a place where we can grow personally and professionally as a team by doing the things we love and by helping others through our expertise; we’re looking for continuous improvement and we’re eager to share our “inner” findings and vision with the outer world.
2. Reason #2 We don’t believe it is still okay to work nowadays without really helping the client pursuing their business goals and eventually getting him to make money. It’s not okay to be “just a vendor”, we want to be part of something big. On top of that, remarkable case histories lead to greater visibility (and therefore to more work).

This is why we’re changing the way we work with our clients.

Now let’s focus on how we’re doing this.

The Very Big Picture

Let’s be honest: we’re not the only studio out there, there are plenty of great agile vendors. However, I think choosing a partner is a very emotional choice.

Over the last year I’ve observed a common pattern in our clients: they deeply understand and share our style, our attitude and motivations.

Our clients like our story and the way we do things, they recognize themselves in our attitude; we establish a deep trustful relationship with them.

How does it work?

The very first step consists of listening a lot. We start breaking an idea into its little fundamentals; we help ourselves using a visual technique we’ve found while shaping our own design method, a silver bullet tool: The User Story Mapping [2].

So we put ourselves in real users’ shoes. Story Mapping tries to describe the whole, longest path, a user can make inside the app by writing post-it notes on a wall in a left-to-right work-flow for each feature.

Story Mapping consists of describing a user’s journey step by step (from left to right, blue cards in the pic) with a detailed list of each step (from top to down, yellow cards in the pic).

Story Mapping is basically a workshop session done directly with the client. We prefer a physical board for the story mapping sessions and then we move the map to a virtual tool (storiesonboard.com does the job really well).

What we discovered in the making

1. Story Mapping’s most valuable output is not the mapping of post-it notes itself but the brainstorming, addressing the doubts that arise, and the decisions taken from the workshop sessions.
2. Story Mapping is an “open” and “easily-readable” tool. It’s designed so anyone can actively contribuite and join at any time: UI designers and developers can give hints evaluating feature complexity, marketing guys can tell their must-have features, sales managers can share their consumer-based point of view. Everyone can and should be involved in the process.

The best part of the journey is the surprise and wonder along the way.

(some guy on User Story Mapping – without even knowing)

The Roadmap

So, the product makes sense. We made the big picture of the product with sufficient details, we even prioritized releases to get an early testable set of features without pretending to build a twelve-month all-in-one project.

What happens next?

What everyone wants to know at this point is how much money he will have to invest. To answer this question we translate epics and themes from the Story Map to an execution roadmap divided in sprints (one or two weeks), with the prerogative to continuously design and code week by week (as the agile philosophy suggests).

Given how many people from our team will be involved, the Roadmap gives back two valuable pieces of information:

1. How many weeks we’re going to work → given the single sprint cost, then multiplied by the number of weeks in the roadmap, you can get the final budget estimate for the project.
2. How much time we’re going to need before we can release something public → how soon we can validate the product with real users.

While this method is clearly not perfect, because of the human factor playing a key role in forecasting future effort (we as humans are not really great at this), we haven’t yet observed actual timings that rose above than 15% – 30% from the initial projections when things changed on the way.

After everything is set we all get to work and once a week we meet with the client and show them what’s been done during the previous sprint and we plan the next to come.

What’s changing.

Since we chose our personal way of helping clients with User Story Mapping and Sprints iterations, we have been able to reach some goals that showed us we’re working in the right direction.

Focus on building the right product

By introducing periodical sprint reviews with both the team members and the client we’ve seen a dramatic change in how work is perceived as a whole. We all started talking as a team of people working towards a common goal instead of chasing some unknown client abstact will. Only by talking directly with designers and developers involved in the project, evaluating together threads and opportunities, it has been possible to do real teamwork with clients.

No more blame throwing over specs or timing: since we shared the vision of building something “effectively working” together, we have stopped arguing with clients on what to build and whether things were or were not included in a fixed contract fee. Also timing has become a shared responsibility, and now “positive” pressure is conveyed to build better plans with the available resources — with no blame.

Eventually this leads to happier teams, a better product and, hopefully, happier users

Team members can feel the company has a trustful relationship with a client: they can talk freely in meetings, they’re in the position to express themselves as professionals at their very best and to do what its needed to get things done.

Share!

Do you have any question for us? Are you working lean as client or vendor? We’d be glad to hear your story and listen to your experience.