Contracting out Digital Products

ON JANUARY 9, 2007 Steve Jobs presented the iPhone. From that day on we have been inspired as never before by sublime technology products from all over the world.

But there is an untold story. The story of how Steve Job’s masked an incredibly complex technology behind a very simple object.

In Apple’s boardroom, it was clear that the prototype was still a disaster. It wasn’t just buggy, it flat-out didn’t work. The phone dropped calls constantly, the battery stopped charging before it was full, data and applications routinely became corrupted and unusable. The list of problems seemed endless. At the end of the demo, Jobs fixed the dozen or so people in the room with a level stare and said, “We don’t have a product yet.”

Wired «The Untold Story: How the iPhone Blew Up the Wireless Industry»

Today, 10 years later, Apple Store alone counts more than 2,7M apps, and the same goes for Google’s Play Store.

We all appreciate the stunning simplicity of famous apps. We all dream of the incredible products we could build if we just had the time.

But software—as every rose—has its thorns.

At Moze we help entrepreneurs and managers to transform ideas into digital products. We design and code products such as web platforms, sites or apps.

Not all of our clients possess technical skills. Maybe they come from marketing or business. They are entrepreneurs and managers, and usually looking for an “IT” (Information Technology) contractor.

A part of our job is to help take consciousness about the fact that building an App is much more than what it seems.

And to succeed you don’t need a vendor, you need a partner. We believe building the right product requires to form a strong partnership relationship based on the values of Agility. We summoned up five lessons learned especially valuable for non-technical founders.

Here’s what we discovered.

1. Plan On Short Cycles
2. A Product is Never Done
3. Software is Hard
4. Time or Scope?
5. Build your Team

1. Plan On Short Cycles

Sometimes we get Request For Proposals (RFP) with a long list of requirements and a requested go-live date.

Cody Simms from Techstars, a startup accelerator, explains in a recent article how 12-month roadmaps are characteristic of the pre-Internet era, when product cycles required long lead time to ship the physical product—while today Internet software, instead, must adapt rapidly in order to survive.

We build products iteratively, and we adjust features and functionality in minutes, hours, or days based on what data and users are telling us.

Cody Simms on Product Roadmaps

Sharing a vision on the general roadmap is good when choosing a contractor because it allows both parties to agree on outcome (what to build). But when it comes to implementation (how to build) we do not think it is good to lock down detailed requirements upfront: simply because you don’t know it all yet.

Many companies know that the most effective timeframe for execution is a period of 6 weeks. Intercom, a SaaS company, perfectly pictures the theory by correlating accuracy and efforts of planning.

We’ve found the 6 week cycle does just that. It helps your team fight for meaningful goals, and gives you flexibility within 6 weeks to adjust and adapt to the inherent uncertainty of shipping product.

Inside Intercom «6 weeks: why it’s the Goldilocks of product timeframes»

Build less. Build better. Build incrementally.

Agile teams usually work in pre-defined time frames named “sprints”: great teams are able to build software people want by balancing efforts between discovery and delivery:

• Discovery sprints: the focus of the sprint is to understand users, the market, testing prototypes, to conduct usability tests.
• Delivery sprints: the focus is on designing and writing software.

This allows the product to be adherent to user needs and expectations, avoiding long development-only cycles before testing the market.

2. A Product is Never Done

We have seen many times people approaching the development of a digital product with this three-step approach: build, launch, wait for them to come.

We, at Moze, see a digital service as a living entity.

When using apps such as Instagram, you only see the tip of the iceberg. It is surprising to discover how much work is being done by the hundreds of engineers and designers of each company working on present and futurefeatures.

Building the first release of a product is just the first step. That’s not the finish line, that’s where you are actually starting.

A huge amount of energy is spent on getting market traction, hiring the right people and building your company culture, organising your team, setting up a process to learn from your customers.

3. Building Software is Hard

Outsourcing software is not like buying a car. Once, we were asked for a “Turnkey” contract. There is no such thing in a tech company.

If your business relies on its digital touch points to provide the service your customers are using or paying for, then you’re building a technology company.

Even if you’re building “just an app”, you should be willing to understand what’s under the hood as much as a Formula 1 pilot must know about engineering, mechanics or physics.

Fast to build, difficult to perfect

Even in the case of an app, as simple as it can appear, the underlying technology is written throughout several layers of proprietary and open source frameworks, scripts and components.

Moreover a modern Internet software today heavily relies on service components made available by other technology companies, for example Amazon Web Services for hosting and computing power.

This is why we are able to launch an app in just 3 months. And it is also the reason why perfection is a long way to go.

Internet software has bugs. And sometimes it breaks too.

The only reliable, widely used way to ensure impeccable software quality is to write less software that does less stuff, and then spend eons honing that tiny lot.

DHH — Creator of Ruby on Rails, Founder & CTO at Basecamp
«Software has bugs. This is normal.»

4. Time or Scope?

The first thing to understand when looking for an agreement to outsource a project to a contractor is to choose a priority between Time (when to deliver) and Scope (what to build).

Are you planning for a big launch event such as an industry conference? Or, instead, do you absolutely need a minimum set of features for an important release?

In Agile, when working with a contractor it is recommended to keep only one variable “fixed”: Time or Scope. Mike Cohn, Agile expert and founder of the Scrum Alliance, describes the tradeoff between fixed-date and fixed-scopedelivery.

Case A: Fixed Scope

• Client: “I want these features”.
• Contractor: “Ok, it’s going to take between 12 and 15 sprints of work”.

Features are known in advance and effort required to complete them is estimated by story points (read more about how they work). Therefore it’s feasible to forecast a delivery window, expressing the time needed in a number of “sprints”—a fixed period of time (E.g., 2 weeks) and costs.

Case B: Fixed Date

• Client: “I have this budget, how many features can you build?”
• Contractor: “You’ll surely get these features, you might also have those”.

A launch date or a budget is the main priority. Project scope (the number of features to build) will be divided into “Will have features” and “Might have features”.

With Fixed Date contracts the delivery window (and its cost) is known. The number of features shipped will depend on the team’s velocity (a way to measure work completed in each sprint of work).

5. Build Your Team

When building a technology company, choosing to outsource all or a part of your product development may be a good boost for the first iteration, since you can count on a ready-to-run team of experienced designers and engineers—instead of waiting for longer hiring and assessment cycles.

However, the market and your users’ expectations will continue to change. And since “A Product is Never Done”, one of the questions you should be asking yourself is how you’re going to keep pace with change.

Either way, the most successful companies we have seen, sooner or later hire the key roles needed to run the product. Marty Cagan, founding partner of the Silicon Valley Product Group, describes the key roles as following:

• Product Manager: the person responsible for assessing product opportunities and defining what to build.
• User Experience Designer: people responsible for developing a deep understanding of the target users and coming up with an appropriate solution.
• Product Marketer: the person responsible for telling the world about the product.
• Engineering: people responsible for building the product.
• Operations: the team responsible for keeping the service running.

Having a team is not only recommendable, it becomes essential when you are about to evolve and scale your product after the first iteration or when approaching a VC.

These are the lessons that we have learned on the go. Have you got other suggestions or experience to share with us? We’d be glad to hear from you.

We think this is the mindset a non-technical founder should adopt in order to have a no-surpise product development experience,

Succeeding in letting users see only the tip of the iceberg: the beautiful simplicity of products we love without perceiving its complexities.