What happened to the R in R&D?

What happened to the research?

Ever wonder what happened to the “Research” in R&D??Now old school, waterfall was the software development gold standard. At the start of each 12-18 month development cycle, the dev team and cross functional product team move from the execution and shipping stage of the previous software release into research for the next one.

We’d think, research, ideate - and, validate.?

This space provided critical time for innovation. Under a disciplined research and validation methodology (we used a process called SynchDev - more on that later), the entire team got out from the four walls and potential endless internal debate to put on our customer and market hats. We’d vet our ideas and hypotheses on the road and collectively hear from the voice of the customer.?

The best part for me? We often learned answers to questions we didn’t know to ask. Simply by asking open ended questions. My favorites are: “What keeps you up at night?” and “What are your top budgeted priorities for next year?” These two give insight to their problems and priorities - that they’re willing to spend money on.?

Of course we had a disciplined approach beyond those two questions. We used a methodology called SynchDev, based on the methodology by Frank Robinson who coined Minimum Viable Product (MVP). He defined MVP as the result of product development and customer development executed in parallel, what he calls “synchronous development.” Robinson, and later Steve Blank wrote about this as well, emphasized the importance of understanding customer needs and market dynamics before fully developing a product or launching a company.

After using the SynchDev research approach in the field, we returned to make key decisions. Now working from the same data and observations, amplified by our unique perspectives - healthy debate ensued and decisions were made. Entire product ideas were sometimes nixed. This saved the company time and money developing a product that didn’t have a market and opportunity cost. We also found breakthrough innovations that changed the face of technology. The MX product platform in my time at Macromedia, for example.?

So, why is this type of approach infrequently seen these days in software development??

The shift from research to development

In recent years the emphasis shifted disproportionately to software development/release. We’ve seen breakthrough innovations in software development processes alone, Agile, Scrum and their supporting technologies like in continuous innovation, continuous release and other DevOps frameworks. The promise of speeding up innovation, time to market and customer feedback loops transformed the way we worked.?

Immediate feedback loops in dev are great. Research is different. Alphas and betas, or continuous release cycles depending on your process, tests “does the feature work as expected”. Research tests “is this right problem to solve, is there a market, and is this the MVP”. Those are two fundamentally different tests and they require an order. I’d much rather find out if we’re solving the right problem before we code it into my product and release it to the customer.?

What drove the shift to development? Emphasis on short-term profit pressures and quick returns on investments. Everyone wanted the Silicon Valley story they see in the movies. What wasn’t emphasized, and perhaps less flashy, were all the iterations, failures, reiterations and how they got there.?

Teams are pressured to execute, but first need a plan and prototype that’s been vetted and tested. Does speed and efficiency in the name of more profits sooner take a toll on innovating and delivering customer value? It reminds me of my kid’s teacher who says, being fast at math isn’t the same as being good at it.?

Implications of neglecting research

Neglecting research has profound implications on short- and long-term innovation. In the short-term, working off a backlog can help maintain current customer satisfaction. But - if your customer base isn’t representative of your ideal customer profile, you’re investing more in features that won’t deliver value to a repeatable and scalable segment you want to win, your ICP. And, long-term, you can miss out on huge shifts in tech you might be particularly suited to win ahead of competitors.?

Think of Nokia and Blackberry for example. In the advent of the smartphone, who was better situated to get to market first with their captured audience, brand and operational fit? Paying attention to changing consumer expectations - versus iterating on what they were already doing - could have prevented their demise. Similarly, Blockbuster underestimated the shift in tech climate and people’s changing preferences and missed out on the opportunity that Netflix nailed.?

I experienced it first hand myself. I was the Flash Mobile Product Marketing Manager when Steve Jobs wrote an open letter to Adobe declaring no support for Flash on the iOS devices. There’s not a great Enterprise mobile app strategy without iOS. Correction, there was none. Granted that story is different, but perhaps we could have gotten ahead of it by building around other open technologies at the time as well - which more ideation and risk taking could have provided. Unlike the other examples given, Adobe is still thriving with their overall innovation.?

Without key market driven data, making strategic decisions, and seeing them through, can be hard. Product decisions then come down to who has the stronger voice, power or influence in the room (that day). Versus leading with market driven data - or being purely innovation driven: giving the market something novel they didn't know they needed (think iPad).?

A call for action: balancing research and development

Let’s put the R back in R&D. It’s not either/or - it’s and. Innovation requires a balanced approach. Agile is here to stay, for a while at least. Until the next thing. In the meantime, let’s consider how Agile was intended to be executed.?

Here’s a quick look back to the original intent of Agile according to founding principles in the Agile Manifesto:?

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

Agile’s original goal wasn’t just about time to market, but about regular interaction with the market, building feedback in and iterating plans cross functionally to deliver the most value. Amen to that! At times, this gets lost in translation and we need to rethink how we execute the ideation and research to innovate within this fast process.?

Some companies got this right. Take Warby Parker for example. While I’m not privy to their precise internal methodology, I learned in TedTalks and articles that they prioritized thoughtful research and market validation alongside development. They took time to research and iterate on their business model, designs, brands etc., before we ever heard of them. Warby Parker continues to focus on research as an investment as evidenced by their move over time from purely ecommerce to the addition of brick and mortar stores.?

A current example of matching research with dev is OpenAI. OpenAI is changing the face of tech and tech supported industries. They continue paradigm breaking innovation in AI capabilities like language generation, image recognition, and game-playing algorithms - driven through their ongoing research in learning, natural language processing and AI safety. And we’re just seeing the start of its use cases and impact on society.?

Mapping Agile with validation

For product teams wondering how to build validation into your Agile process, we can do this without having to revert back to old school ways. In addition to fast and thoughtful development practices, research methods can be efficient, fast and iterative - as Agile decries.?

For instance, you can build blocks of time within your sprints dedicated to research and validation. Take a sprint or two and commit the teams’ time and resources to hitting the road to see customers (or presumed ideal customers), using a tried and tested process for validating ideas, like an abbreviated version of SynchDev.?

We used critical tools like the $100 test, asked open ended questions, and had a scribe document everything the customer said. We observe them in their environments, along with the workarounds they don't know they built to solve problems they didn’t notice they had.? These are a few examples of what we did in SynchDev, there’s more.?

I’m not just making this up. Frank Robinson was the co-founder and president of SyncDev, the process I refer to here. You know him even if you don’t. He introduced the now ubiquitous term Minimum Viable Product (MVP) in 2001. He explained: an MVP is the result of product development and customer development executed in parallel, what he calls “synchronous development.” Much of the methodologies and approach created by Frank Robinson had profound influence on the Silicon Valley tech companies we revere today.??

A litmus test

Investing in fundamental research is a must for sustained innovation and future growth. Keep the Agile Manifesto in mind when you’re planning your next sprints and ask yourself, who’s driving this list of requirements and does it chalk up to a strategy to win a market or sub-segment of one? Will we be innovating or iterating for a group of customers we already have and does it map to your ICP? Have we taken time to validate our ideas and come up with new ones? If not I urge you to advocate for a renewed focus on research in your org.?

It doesn’t have to be an all or nothing approach. Like Agile, research can be iterative and ongoing, and - should be. If you want to sustain a unique position in the market, time to think, ideate and validate is going to be the difference between those who win and those we forget.?