First there was waterfall. Then came agile. Agile begat lean. Now design thinking is having its moment in the sun. 

Software development has changed tremendously in the last 15 years. So how do product managers and developers collaborate today to produce enterprise software? 

The Apple Way

When I worked at Apple from 2000 to 2004, Mac OS X was built using the waterfall methodology. Product managers would collect input from customers and develop a marketing requirements document (MRD). Engineering would produce an engineering response document, which estimated how long each feature would take to develop. Then we’d meet to negotiate what would go into the software we intended to release 12 to 18 months later.

Product managers would meet face-to-face with the engineering managers on a regular basis. However, communication between product marketing and engineering was primarily via email, even though the teams were in adjacent buildings.

Each major component of the operating system had a separate development team. Each team had one quality assurance engineer who would test the code before it was committed to the release. A separate engineering team developed the user interface. And the engineering management organization kept the schedule, built and integrated the software for each release.

That’s the way software had been developed for decades. Not anymore.

Becoming Lean and Agile

Coincidentally, in February of 2001, a group of seventeen software development professionals got together at a ski resort in Utah. They wanted to create an alternative to “documentation-driven, heavyweight software development processes” like the ones described above. The result was the Manifesto for Agile Software Development.

Lean software development arrived in 2003. It combines agile principles with the Japanese concepts of kanban (with a scrum board instead of parts bins) and kaizen, or continuous improvement.

Lean and agile software development can be summarized as “empower[ing] a development team to think, plan, develop, ask and iterate as quickly and efficiently as they can.”

Ironically, the think and plan stages are not that different from the waterfall method. There’s still a lot of (too much?) process around gathering customer requirements and building a business case, which can take a long time. So “quickly” doesn’t really kick in until the develop stage.

Agile development (lean or otherwise) is done in sprints, with each sprint typically lasting two weeks. At the end of each sprint, the goal is to have a “shippable product.” That’s right, functional software — developed, tested and released in 14 days, not 18 months. Of course, each “release” won’t be incredibly feature-rich, but that’s the point. The goal is to develop only the features customers actually want, not what the product managers or developers think the customers want.

Customer Requirements

So how do software vendors know what customers want? Well, honestly, most don’t.

In the waterfall days, we asked customers what they thought they wanted. We’d develop software against those “requirements,” and then we’d come back a year or so later and ask if we’d developed what they used to think they wanted. We were usually about half right.

When agile came on the scene, we’d (still) ask customers what they thought they wanted, and then we’d develop a few features, deliver the software and get feedback. We’d still be half wrong, but at least we learned that sooner.

The problem with asking customers what they want is that they never know what they want until they see it. (You might think I’m joking or jaded, but that’s a scientific fact.) That begets a process of elimination — you develop what they don’t want until you finally develop what they (mostly) do want.

Rethinking Thinking

With design thinking, instead of defining requirements by asking the customer what they think they want, you observe the current situation and see what people actually do versus what they tell you they do to uncover the underlying want or need. You ask “Why?” enough times until you get to the root problem. 

As Fast Company put it, “The goal of the definition stage is to target the right problem to solve, and then to frame the problem in a way that invites creative solutions.” Once you have defined the problem, you develop and consider a few alternative solutions, pick one, implement that and get customer feedback.

However, even with design thinking, the customer feedback still comes at the end, after you’ve invested valuable time and treasure to develop and deliver something. That’s still a “bassackwards” way of developing software.

There's Another Way

My company's not perfect, but we have been around for 35 years. And with age comes experience. With experience comes wisdom and the willingness to share what we’ve learned with others.

We did waterfall development for a quarter century. Then, we got lean and agile. Then along came some people and tools that allowed us to take our development to a whole new level. And here’s where I bring this story back to collaboration.

Collaborating with customers

We are about to make a(nother) major change to how we develop software. We’ve already done a lot of thinking about the root problems our customers deal with (that’s time-consuming, but we have a few ideas). Instead of waiting until after we’ve released software to get input from customers, we’re going to take a page from Google’s book to make sure we get the look and feel of the user interface (UI) right before we write any code. That’s right, function will follow form.

We’ve been working with an external user experience (UX) firm to help us ideate and iterate a new user interface (I highly recommend getting that external perspective). We’re about to get customer feedback on the new UI/UX. We plan to iterate the UI/UX until the customers are happy (i.e., a UI “release”). Then we’ll write code.

Once we code a feature related to the “released” UI, we will reengage our customer focus group to do usability testing, to make sure the UX of the product “flows” well. We will be using some software and surveys to gather, aggregate and validate the customer feedback.

Collaborating as a team

We use a number of tools to collaborate on just about everything. We use Slack instead of email to communicate internally among teams and with external resources. We use Google Apps for Work to collaboratively develop and share content. Our UX, sprint and other meetings are conducted in Google Hangouts (we have team members in multiple time zones). 

We conduct asynchronous stand-up meetings using Tatsu (integrated with Slack). We use JIRA to manage our sprints and backlog. And we’re about to try out a new tool that we think can provide a single view of — and highlight the dependencies between — our marketing and development projects, enabling better collaboration, increased speed and greater efficiency. We’re always looking for new ways to increase our speed, efficiency and effectiveness.

Will these methods and tools work for you? Some might, even if you don’t develop software. Consider this an ideation exercise, the goal of which is continuous improvement. Think about your people, processes and technologies. Why are you doing what you’re doing, or using what you’re using? How might you improve how you collaborate with your customers and colleagues?

If you think long and hard enough, I bet you’ll come up with all sorts of ideas.