Introduction

For decades, the economics of software development were shaped by the cost of engineering labor. Clients paid for engineering labor, and consulting firms organized themselves around the efficient deployment of that labor.

Projects typically followed a familiar structure. Business analysts gathered requirements. Architects designed systems. Developers implemented them. QA teams tested them. Documentation followed.

Progress depended largely on how many engineers could be applied to a problem and how effectively those teams were coordinated. It is worth noting that writing code was never the majority of the work involved in building software systems. In many projects, the write/test/debug loop occupied only 20–40% of a team’s effort, with substantial time devoted to requirements clarification, design, integration, testing, and coordination.

Recent advances in artificial intelligence, particularly the emergence of coding agents, redraw the map of where human judgment matters most, and how teams should be organized to deliver it.

AI coding agents do not eliminate the work involved in building software, but they change where the effort concentrates. As the cost of turning clear specifications into working code declines, the center of gravity in software projects shifts toward defining systems clearly and evaluating how they behave in practice.

When code becomes cheaper to produce, the center of gravity in software projects shifts from implementation to specification and system definition.

What This Means for Software Owners

For product owners responsible for turning ideas into working systems, these changes translate into several practical advantages.

Product owners can test ideas earlier, see working prototypes sooner, and answer feasibility questions through small experimental implementations rather than long design debates.

Smaller teams also mean product owners can work more directly with the engineers responsible for delivery, and iteration becomes less expensive as AI tools regenerate code and tests quickly when designs change.

Two developments are especially significant: 1) the ability to focus engagements more strongly on delivery commitments rather than billable hours, and 2) the movement of engineering activity earlier into the specification phase of the software lifecycle.

From Billable Hours to Delivery Commitments

Traditional consulting engagements are built around time. Teams are staffed, hours are tracked, and progress is often measured by the amount of engineering effort applied.

This structure developed because software creation was inherently labor-intensive. Writing code, building tests, and producing documentation all required sustained manual effort.

Modern AI coding agents transform this dynamic.

When a system’s behavior is clearly specified, coding agents can generate substantial portions of the implementation: code scaffolding, tests, configuration, and documentation. They can explore variations quickly and regenerate artifacts as designs evolve.

The result is that progress becomes less tightly tied to the number of developer hours applied to a project.

A small team working with effective AI tooling can often produce the output that previously required a much larger engineering staff. The limiting factor becomes, not labor capacity, but the clarity of the system being built.

This shift naturally changes how consulting engagements are structured.

When the marginal cost of producing code decreases, the emphasis moves away from selling hours and toward delivering defined capabilities. For product owners, success has always hinged on working systems, validated functionality, and measurable progress toward operational goals. With AI tooling, we can structure engagements around these deliverables instead of the effort to produce them.

Coding Agents Move Development Earlier in the Lifecycle

AI-assisted development also changes where engineering work happens in the lifecycle.

Historically, software projects progressed through distinct phases: requirements gathering, system design, implementation, and testing. Different roles dominated each stage.

Coding agents begin to blur these boundaries.

Modern AI development tools perform best when given structured specifications — clear descriptions of system behavior, data structures, workflows, and constraints. When those inputs are well defined, agents can generate large portions of the implementation and testing scaffolding automatically.

This shifts developer activity earlier in the process. Engineers increasingly participate during specification, because the quality of those artifacts directly affects how effectively coding agents can operate.

Development becomes an iterative loop: specification, agent generation, human review, and refinement. In practice, this cycle can move much faster than traditional development processes.

The Continued Importance of Business Analysis

AI-assisted development does not eliminate the need for business analysts or requirements work. If anything, it raises the importance of clear specifications.

Coding agents are highly capable when system behavior is well defined. When requirements are vague, automated output tends to amplify that ambiguity.

Business analysts increasingly translate business intent into system behavior, ensuring that systems reflect real-world processes, regulatory constraints, and user needs.

Rather than just producing static documents that are handed off to development teams, analysts and architects work together to produce specifications that guide automated implementation tools.

Paired Specification Work

Many teams are experimenting with closer collaboration between business analysts and senior engineers.

Instead of separating requirements gathering and system design, these roles work together in extended working sessions focused on turning business workflows into precise system specifications.

These sessions often include clarifying product owners’ objectives, identifying system boundaries and integrations, defining data models, and producing structured specifications that guide AI-assisted implementation.

This collaborative approach reduces translation errors between business and technical perspectives and allows architectural implications to surface earlier.

Design in an AI-Assisted Development Environment

User experience and interface design are also evolving as AI-assisted development becomes more common. The core responsibilities of UX designers — understanding user needs, shaping workflows, and ensuring clarity of interaction — remain unchanged. However, the speed at which designs can be explored and validated is increasing.

Historically, UI and UX design often progressed through a series of mockups and clickable prototypes before implementation began. Designers produced wireframes and interaction models, developers interpreted those artifacts, and working software appeared later in the project lifecycle.

AI-assisted development compresses this process.

When interface behavior is described clearly, coding agents can generate substantial portions of the UI implementation: layout structures, component scaffolding, and interaction patterns. As a result, teams can move from conceptual designs to functional prototypes much earlier in the project.

This shift changes how design work unfolds. Rather than producing static mockups that are later translated into code, designers and engineers can now collaborate on specifications that directly guide automated implementation tools. Teams use structured design artifacts (e.g. component definitions, workflow diagrams, and interaction rules) as inputs to AI-assisted development.

In practical terms, design and implementation begin to overlap. UX designers work closely with engineers to refine user workflows while prototypes are already running. Instead of evaluating simulated interfaces, teams can test real system behavior and refine designs through rapid iteration.

AI also lowers the cost of exploring design alternatives. Multiple layout variations or interaction flows can be generated quickly and evaluated with product owners and users before committing to a final direction. This encourages experimentation and allows teams to converge on usable designs more quickly.

At the same time, the importance of good design does not diminish. If anything, it increases. When generating interface code becomes easier, the limiting factor becomes clarity of the user workflow and the coherence of the interaction model.

AI can accelerate the production of interface artifacts, but it cannot determine whether an interaction model truly solves a user’s problem. Designers remain responsible for ensuring that systems are understandable, efficient, and aligned with real user behavior.

For consulting teams, this often leads to closer collaboration between designers and engineers during early project phases. Working prototypes appear earlier, feedback cycles shorten, and user experience evolves in parallel with system implementation rather than preceding it.

In effect, AI-assisted development moves UX design closer to the center of product definition. Instead of being a preliminary step before engineering begins, design becomes an ongoing activity that shapes how automated development tools generate the systems users ultimately experience.

Smaller Teams, Faster Iteration

As coding agents take on more of the mechanical aspects of implementation, delivery teams often become smaller but more experienced.

Rather than relying on large groups of developers to produce code manually, smaller teams of senior engineers can guide AI tools to explore solution spaces quickly and converge on working systems.

The constraint becomes not the number of developers available but the clarity of the system’s definition and the discipline applied to reviewing automated output.

Conclusion

As the cost of producing code declines, the center of gravity in software development shifts toward defining systems clearly enough that they can be generated, tested, and refined rapidly.

For product owners and business leaders responsible for turning ideas into working systems, this shift creates a new opportunity. In traditional development environments, the people shaping a product vision were often several layers removed from the engineers implementing it. Ideas traveled through requirements documents, design reviews, and development queues before they appeared as working software.

AI-assisted development shortens that distance.

When small teams can translate well-defined specifications into working prototypes quickly, product owners can engage much more directly in shaping the system. Concepts can be tested earlier, assumptions can be validated with working software, and refinements can happen in smaller, more frequent increments.

This changes the rhythm of product development. Instead of waiting for large implementation cycles to complete before evaluating results, product owners can move toward continuous adjustment — clarifying requirements, observing how systems behave, and refining the design in rapid iterations.

In this environment, the most effective product owners will not simply define requirements and hand them off. They will actively participate in shaping specifications, reviewing working prototypes, and guiding the system toward its intended outcomes through ongoing collaboration with engineering teams.

When code becomes easier to produce, the distance between vision and implementation shrinks. The product leaders who benefit most from this shift will be those who use that proximity to shape their systems directly — learning faster and refining them with greater precision.

When Code Becomes Cheap was originally published in Blue Rocket Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blue Rocket has built dozens of products for startups and companies looking to expand their software product portfolio. Every one of our customers eventually wants our help to transition to an internal team.

Want a fast start on your project, but don’t want to keep an expensive contract team around for years? Here’s what’s worked for our customers.

1. We start by helping our customer recruit the right internal people.
2. As new internal team members join our customer, we embed them in our team.
3. We coach them and teach them and eventually they outnumber us, and we’re embedded in their team.
4. Then, when the internal team is self-sufficient, we disappear.

Recruiting

1. Recruit the right people early in their career.
2. Embed them in a team with experienced members.
3. Assembling an experienced team takes a year and a half. If you don’t already have one, we provide starter yeast.
4. They will grow quickly into experts.

Team structure

Blue Rocket projects start with a project manager, a lead developer and a junior-to-mid-level developer. Usually the project manager and the lead developer are around for most of the arc of our participation in the project.

On-the-job coaching

We help recruit your first or next developer, usually more of a junior level. We embed them in the team and we coach them: our process has built-in coaching: We teach the team to break down tasks into day-sized chunks and we teach them to create a work plan for each day. Each day, the team reviews all the code that’s produced that day. The review of the work plan gives the team a nice touch point to help the new developers plan their day and how they’ll tackle the task. The code review gives the team a chance to give and receive immediate direct feedback on what can change about how they executed the task to make it even better. That combination is remarkably fast in bringing people up to a very productive level of execution ability.

Two-week sprints

Classically we’ve used two-week sprints because it gives us a cadence where each sprint is short enough that we can predict what’s going to happen inside those two weeks. But each sprint is long enough that at the retrospective, we have plenty to talk about. Two-week sprints have worked well for us but we’ve been experimenting lately with continuous Kanban style work on similar projects. It’s a little early yet to know which we like better and we’re still keeping the two-week retro cadence even in that.

Daily rituals

We work with user stories, and very few user stories are accomplished in a day. So we take a user story apart and split it into day-sized tasks. We’ve developed a canonical list of task types. It may be laying out a screen. It may be implementing a gesture. It may be implementing the call to the backend for a dataset. We purposely make these small so that we can always accomplish it in a day — sometimes we’ll get more than one of them done in a day. Sometimes we’ll get one and a half or two done. We can pretty always count on getting one of them done, and that gives us fodder for the cadence of: plan → work →review → test, rinse and repeat.

Plan, work, review, test

This cadence creates a very reliable throughput for the team. It also gives many people on the team the chance to see each unit of work and offer feedback — so that it’s not just one person in a silo who comes back down from the mountain after two weeks and everybody’s dismayed by what he’s produced because it wasn’t what they expected or wanted. We have this constant feedback that lets us adjust on the fly and push it through the team so it meets everyone’s expectations.

Recruiting for culture

We’re not focused on tools. Especially when we are recruiting junior developers or QA trainees. We aren’t worrying about: “Are you good at JavaScript or are you good at react? Are you good at Swift?” It’s too early in their career for that to matter. What we focus on:

1.Self-motivated
“Are you self-motivated, whatever the technology? Have you already built something on your own?” It’s a must-have for people who want to be developers.

2. Teachable
“How teachable are you?” I always include a lot of questions in interviews that relate to mistakes they have made, what lessons they learned from it, and how would they handle it differently today? If they won’t admit to a mistake, then then they won’t allow me to correct that mistake, right? I need them to have that humility, to be able to reference concrete examples where they made a mistake and how they fixed it, or how they would do it differently today to fix it.

3. Curious
Curiosity is non-negotiable. Curiosity is an engine that pulls the train for a lot of our work. If you’re not curious, then you’re not going to have that spark that leads you to explore and figure out the answer to the problem. Our days are just filled with problems. As a developer or as a QA specialist or as a designer, they are here to learn the constraints of this problem and create a solution that addresses it. So that curiosity is non-negotiable. This has been really successful as a filter.

Apprentice as QA

With these three things, people are ready to start as QA trainees. And as soon as they start knocking QA out of the park — which they all have so far — then we’re ready to start offering them development tasks. Or if they’re more drawn to some other area, maybe they’re showing a flair for organization and we want them to help the project manager as an assistant or a project manager trainee. But in any case, it’s proven to be a really successful combination of traits, and people make rapid progress in the first year.

The Blue Rocket Manifesto: Build  Products & Teams was originally published in Blue Rocket Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

Reason #1: No market need — 42%

Yikes! How did this happen…

VC Andy Rachleff says he asks every founder:“What do you uniquely offer, that people desperately want?” It’s hard to predict what people want desperately, it’s even harder to predict when they will finally want it.

The key to lowering this risk, is a tight focus on the user (or customer). You should be carefully identifying who is your target audience and who is not. You must examine their unmet needs, their moment of need and their alternatives to your solution. If you are bootstrapping your startup, you may not have the resources for a pivot. So getting it right early can make the difference in realizing your dream.

Reason #2: Ran out of cash — 29%

You might find more cash, eventually. But by the time you do, the market has moved on, your target has changed. Much better to adjust for the wind and make your first shot count.

It’s important that you sit down and define your product carefully. You believe powerfully in your idea and you have thoughts about how to accomplish it. But you need to communicate these ideas to investors, partners, employees and more. And you will benefit from hearing other people’s ideas. Get someone to challenge your assumptions, someone to push your boundaries, someone to make you spell it out. The earlier you converge on the right set of product features, the more budget you will have left to improve your product, to service your early customers and to respond to their feedback.

Reason #3: Not the right team — 23%

The earlier you choose your team, the less choice you have. People who join nascent startups, especially pre-funding startups, can fall into these categories:

1. People who are already so committed to solving the problem you are addressing, that they would have created their own startup if you hadn’t found them. If you meet a person who adds energy, honesty and humility to that commitment, pull out all the stops to bring him or her on board.
2. People who have very few choices. You can find people who will work for equity or low salaries because their other options are limited. But there is nothing about that circumstance that leads you to the right people to make your venture successful.

Avoid rushing into early personnel choices that are likely to leave scars on you and your startup. Once you have the right situation, one that draws the right people, you can make smart hires.

Reason #4: Get out-competed — 19%

For a company that is pre-product there is no competitive vector more critical than speed to market. You can’t learn everything you need from actual users or customers until you put a product in their hands. If your competitor is there first, their lead will be permanent unless they really screw up. Be better, faster, stronger! Don’t count on a stumble by your rival.

Reason #5: User un-friendly product — 17%

Ignoring your users’ needs is a critical weakness. If your product is hard to use, then the problem you are solving had better be life-changing. Otherwise your users will abandon the product before you can learn enough to improve.

Stepping Wide

In conclusion, to avoid the top five dangers to startups:

1. Focus sharply on the user.
2. Get early feedback.
3. Hire deliberately.
4. Enter the market swiftly.
5. Design the user experience thoughtfully.

Blue Rocket

A company like Blue Rocket can help with all of these precautions and more. We build first products with proven teams, proven methods and know-how that stretches across hundreds of startups.

We start by sitting down with you and detailing your target audience, your competitive landscape and the difference your solution will make in the lives of your users. As your product workshop continues we encourage you to think more widely than ever. But as we wrap up, we help you to focus on the essence of your idea and the minimum feature set required to test it in the market.

Also, Blue Rocket has learned much about right-sizing your user experience design to your budget, your audience and the problem you are solving. Let us show you what we’ve learned here!

Blue Rocket is a digital product development company based in San Francisco. Through strategy, design, and engineering, we help great companies build powerful digital experiences — the right way. Find us at www.bluerocket.us

5 Reasons Startups Fail (And How to Step Wide) was originally published in Blue Rocket Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Best Strategies For Growth Hacking Your Mobile Application

The holy grail of app growth is when your users move the app icon to their home page and open it multiple times a day.

When it comes to growth hacking a mobile app most entrepreneurs and developers think that their big idea will explode over the internet overnight. The truth is, growing an app isn’t just restricted to online. The old saying goes, “It’s better to have 100 people love you, than to have 1000 people that kind of like you”. If you can dominate a specific location or community of people, chances are that these people will be your mobile app’s evangelists and help you growth hack your product without you telling them. Free marketing or word of mouth marketing is the best and most effective type of marketing strategy out there.

1. Narrow your Niche

Sometimes it is much more effective to narrow down your niche depending on the type of mobile app you are developing. If it is a location-based app then it would be wise to test out a very tight cohort of users. Tinder, the dating app, is a good example of this. Tinder held frat parties at USC with entrance being conditional on having downloaded the mobile application. Put yourself in the users’ shoes. If you were invited to a frat party and arrived at the door with the only requirement being to download an app, you would most likely do so. Doing this, Tinder was able to growth hack and grow their database of users every night. Then word of mouth just took off from there.

2. Build Community Channels

If you are planning to growth hack your mobile app, then you should attack every channel you can target and come up with new undiscovered channels to target as well. Tinder’s example teaches us that targeting a smaller tight cohort of people is just as effective as targeting a large number of audience. College campuses are connected like ant farms. College students go home on holidays and chat with their friends over the social media networks. Almost every college student owns a smartphone. This allows word of mouth to spread extremely quickly and grow.

3. Mix Analog with Digital by Going Local

Another example of this is Sprig. Sprig growth-hacked their service locally like Tinder, but Sprig used another strategy. Sprig went around their local pier and all around the city passing out flyers. They did not target a specific tight cohort of people, but instead targeted a specific location of strangers. After people completed their first order, Sprig would follow up with them on reviews and request a referral which draws more user back into the retention loop. Be creative and start growth hacking your mobile app!

4. On-page App Store Optimization

For anyone who’s unfamiliar with app store optimization, it is the process of optimizing your app so that it ranks higher in the app store’s search results. Essentially, it’s not that dissimilar from search engine optimization — the process of optimizing your website so that it ranks higher in the search engine results.

However, ASO is decidedly simpler than SEO. Unlike the web’s organic search results, app positioning is determined primarily by two key factors: the text (i.e. keywords) used in the app’s title, description, and keyword list, and the actual performance of the app, e.g. it’s ratings and reviews and, of course, how popular it is.

Keyword research for ASO can be approached in much the same way as keyword research for SEO or PPC. You’ll probably want to begin your research with Google’s Keyword Planner. Pay attention to the search volume and competitiveness of relevant keywords, just like you would when carrying out keyword research for any other medium.

Beyond that, there are a number of app specific tools that can assist you in your keyword research. Sensor Tower is arguably one of the best known and most popular but App Mind and the App Store section of Keyword Tool are worth a look too.

5. App Store Feature Hack

There’s a little-known strategy to help your app get featured by Apple. Before we get to that, it’s important to know what Apple is looking for in your app.

Most developers know that they can email appstorepromotion@apple.com to pitch their apps for a possible feature. However, within Apple, there are “app store managers” for each app category.

Using a LinkedIn search for “app store manager,” you can find out how to contact the right person to pitch at Apple.

Because Blue Rocket has successfully identified and helped our clients create new and innovative features this is an excellent way to drive attention directly from Apple.

Use the Email Hunter Chrome extension, because it automatically creates an “email” button within LinkedIn that reveals the person’s email address. The software makes an educated guess of the email, so sometimes you may get a bounce back.

6. Titles and Your App Name

In the app store, your app name is also your app title, which is the equivalent to the <title> tag of a webpage.

It needs to serve two purposes:

1. Enticing users to learn more about your app
2. Providing clear clues (usually through keywords) as to the content of the app

Apple’s App Store allows titles up to 255 characters in length, however, depending on the device being used, only the first 25 or so of those will show in organic search. Any characters that follow will be hidden.

It’s worth considering then, how a truncated title will appear to users and affect click-through-rates (and subsequently downloads). It’s pretty imperative that you ensure users can understand what your app is about from those 25 characters.

To get an idea of how your Apple app listing will appear in the search results, use the StoreFront tool.

7. Off-page App Store Optimization

There are two key elements to off-page app store optimization you need to be aware of: ratings and reviews, and (in the case of the Android app store) links.

Ratings and reviews

The search function of an app store operates like any other search engine: it wants to serve the best possible results to the user. This means, along with showing results that match the keywords used, serving up apps that have received a good response from other users — namely, good reviews and a high rating.

Unfortunately, your users will rarely come and rate you without prompting — most of the time, you have to ask. The most obvious way to do this is with an in-app pop-up.

Unfortunately, in-app pop-ups suffer from one inherent flaw: they interrupt the user experience while they’re engaging with the app.

While there’s no easy way to get around interrupting your users, you can boost the odds that they’ll complete your desired action by making said action as easy as possible for them to complete.

8. The Exclusive Strategy for Public Relations

What is it? You give a big publication like TechCrunch, Social Times, AppAdvice or BGR the first right to publish your announcement: product release, update, funding, etc. Big sites love getting an exclusive, because it means that they will be the first to write about the announcement, which generally leads to the other big websites linking back to them as the source.

It’s a win-win strategy, because they get traffic and backlinks — and you get coverage.

The key to success for this strategy is to start early. You want to start pitching about two weeks before your launch date. You should only pitch the exclusive to one publication at a time, and be sure to follow up only once. If you do not hear back, you can move on to the next publication.

Blue Rocket has many successful ratings strategies that can be integrated seamlessly and successfully into your app.

Blue Rocket is a digital product development company based in San Francisco. Through strategy, design, and engineering, we help great companies build powerful digital experiences — the right way. Find us at www.bluerocket.us

Growth Hacking Ideas & Strategies was originally published in Blue Rocket Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

Three Steps to Successful New Product and Service Development

Do you want to increase the success rate of new product and service development? Most executives do because a stream of successful new products and services is among the top financial drivers for most companies. Happily, there is a wealth of research that offers a very clear idea of how to improve your success rate.

With so much interest in innovation and branded product management methods, it’s time to step back and zero in on the primary drivers of success so that you can lead your organizations to better decisions. In this article I break down the topic to help you apply common sense, experience, and most importantly data from hundreds of projects and companies to help you sort out fad, fact and fiction. You will need to get three things right: the product or service, the team and committing your executives to a successful operating environment.

You Can Improve Your New Product Success Rate

Not sure yet that you should be focused on your success rate? That’s OK, you may find the idea appealing but think that there isn’t much headroom to get better — that all these years building products has enabled us to wring out the best practices and use them consistently. It turns out that this has not happened.

Success rates in product generation are surprisingly low. In a later post I’ll go into this in more depth, but for now, I’ll just share a few of the more optimistic numbers. Robert Cooper’s research (2011) and Cooper and Edgett (2012) indicate that products that launch have a success rate of around 60% and 50% respectively. This squares well with a review of research on innovation success rates (Castellion and Markham, 2013) that put the post-launch success rate at about 60% as well. Other studies break out success rates by industry, but these are among some of the higher averages.

To be fair, not all concepts should make it to launch. For now, let’s just say that 60% is optimistic given that some pre-launch failures constitute waste. Further, more aggressive innovation projects that create value that is new to the world or at least the company have much lower success rates. Estimates are as low as 5% (Keeley et al, 2013). Pick your favorite metric and you will be left with the conclusion that there is huge opportunity to do better at generating successful products.

Another reason for overconfidence in product generation occurs in mid-size companies. Let’s say your company started off with a single product that was a hit and has been able to build itself into a mid-size company with a stream of minor enhancements and marketing. There are two reasons that optimism may not be warranted.

First, there is no law of small numbers… you have been up to the plate once and hit a double. While wealth has been generated, the results from a single swing at the ball doesn’t give you a batting average… you may well find that success eludes you in future programs. What is pernicious about this scenario is that your initial success may get in the way of learning, leading to a desire to repeat things as you did them before even when your success may have been despite the approach you took.

Second, you are now in a different scenario for new product development. You have assets to mind including a brand and a customer base. The consequences of failure are higher. This is arguably the most important time to step back and make sure that you are using the best tools available to optimize your success rate.

How to Improve Your New Product Development Success Rate

OK, so you’re still reading, which I will take to mean you are interested in improving your success rate. Great! I’ve summarized below three steps for optimizing your chances of success. You may notice that I do not refer to specific product or technology generation methods. It’s not that you don’t need a good method… you do. It’s just that the steps to success are independent of any specific method.

Build the Right Product

Getting the value proposition right and then delivering it in a compelling product or service is the lynch pin of successful new product development. In turn, the primary driver to this step is gaining and applying a deep understanding of your market and your customers.

One of the single most consistent and durable research findings is that to build the right product and message it effectively, you need to understand your market and your users (Bacon, et al 1994) and just as important apply that knowledge to your project (Ottum and Moore 1997, 2003). Failure on this dimension can show up anywhere in the product generation cycle from concept and prototype testing to the messaging and response to released products.

Researchers have also confirmed the value of a core tenet of customer-centered design — continuous customer involvement from ideation through launch drives success (Cooper, 2017; McKinsey and Company, 2010). McKinsey and Company summarized situation well: “More than 80 percent of the top performers said they periodically tested and validated customer preferences during the development process, compared with just 43 percent of bottom performers. They were also twice as likely as the laggards to research what, exactly, customers wanted.”

The logic of de-risking projects through customer feedback is likely to apply to other project risks as well. Risks may include technical feasibility, channel fit and so on. Although I am not aware of any definitive data on the subject, where there is doubt, quick validation and refinement of a product and business system makes sense. This approach has gained popularity in recent years to generally positive reports, and has been successful for my teams. For example, your new product may require a new distribution channel that requires the cooperation of new distribution partners. Quickly confirming cooperation or modifying the business system to gain it is a good bet.

Get the Team Right

Cross-functional product teams with open communication, committed time, and a defined yet flexible product generation process consistently distinguish top performers from the rest (Nakata and Im, 2010; Edgett, et al (2011); Cooper and Edgett 2012). OK, that is a lot to pack in to getting the team right, but the findings are clear that both the “who” and the “how” of the team are important. Regarding the how, success favors those who have a well-defined process… not just a picture on a slide. It needs to be used, improved, and be flexible– one that can scale to different size and types of projects.

The value of engaging a cross-functional team is brought home by a related finding, that projects that innovate across multiple dimensions of a business system are more likely to succeed than one-trick ponies (Keeley et al, 2013). This is interesting because the execution difficulty is considerably higher with multidimensional innovation. Cross-functional teams are especially important in understanding how to innovate across multiple dimensions of your business system and how to be successful in implementing those innovations. Products that are new to a business or new to the world are most likely to require the most multi-dimensional innovation. While this clearly raises the difficulty level of producing the products, it is associated with higher performing businesses Edgett, et al (2011).

Commit Your Executives

Executive support improves your new product success rates. However, there is more to it than just being supportive. Providing the monetary and staffing support and a degree of participation is essential. Kachouie and Sedighadeli (2015) summarized the bigger picture well: “This research confirms that top management with an entrepreneurial orientation, including autonomy, innovativeness, risk-taking, pro-activeness, competitive aggressiveness, international orientation, tendency to learn and need for achievement in different organization levels have a determinant role in the success of NPD.” This same finding is what Cooper 2015 refers to as “…fostering an innovative climate and culture” and “… is among the most important best practices uncovered in our many investigations”.

Finally, executives are responsible for ensuring that the objectives for the development effort align with an overall strategy and that the goals of the specific program are clearly articulated in the context of that strategy. Interestingly, there is some support for the notion that the business and technical goals can evolve during development as the team learns and adapts, but need to be crystallized before launch Baker, et al 1986.

In Summary: The Three Steps to Success

So now you have the primary drivers to succeed at new product development. Not just my opinion or anecdotes from popular consultants, but the findings from hundreds of projects. Stick with these themes as your guide and don’t get caught up in the product management fad of the week. Instead, focus on these three areas:

• Set your team up to gain deep insights about your market and customers. Insist that they test and iterate their concepts, designs, and business models throughout the process with your customers and partners. Use team members who are pros at this whether they are internal or external.
• Ensure that you have a cross-functional team with open communication whose first “identity” is to the project team. Worry less about the specifics of the process they use than that it is flexible, documented, and open to modification and gets used.
• Provide executive support to ensure that the team has the required resources and that they have an environment that encourages the entrepreneurial and innovative behaviors you are asking for.

Those three steps will enable your organization to have higher success rates than your competitors.

Want to work on innovation and new product development at your organization? Drop me a note at Tom@BlueRocket.us.

Blue Rocket is a digital product development company based in San Francisco. Through strategy, design, and engineering, we help great companies build powerful digital experiences — the right way. Find us at www.bluerocket.us

Success in New Product Development was originally published in Blue Rocket Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recent reports ( Kif Leswing @Business Insider and John Gruber @Daring Fireball) indicate that Apple is lobbying Indie developers to switch from the traditional one-time purchase fee to subscription models based on periodic fees (monthly, annually, etc.).

The discussion is focused on paid apps that provide ongoing services, in which user fees are the main source of revenue for the app developer (e.g. productivity, utility apps, games, etc.), and does not include free apps that provide indirect revenue through their support of the underlying business of the developer and/or are based on advertising (e.g. large social media apps and restaurant ordering apps).

At Blue Rocket we welcome this development, as all parties will ultimately benefit — the User, the Developer, and Apple.

Why is this? Well, let’s start with the User.

It’s true; the user will have to pay more. So why is it within their interest to support a shift to a subscription-based service? What will this increased cost provide for the user that they don’t currently have?

A frequently used or very specialized app, especially purchased, is important to the user. It may be a productivity or utility app that the user has invested time and energy to set it up so it works for them and their specific needs; Or it’s an app that supplies regular and timely information; Or it provides a tool or service in a unique and novel way, consistently over time. Regardless, the user has a strong incentive to ensure the app continues to work.

A subscription to one’s favorite app will help ensure that the app continues to function and improve. And a user’s continued use of the app will become a motivating drive for the developer who in turn will strive to incorporate new features to keep the user engaged with the service. In essence, the subscription is an insurance policy that will ensure that the app continues to delight.

A small investment will have large returns. A subscription for one’s favorite app is not going to cost significant amount of money. More than likely, it will be a few dollars a month or year; a small cost for the continued service of one’s favorite app.

How does the subscription help Developers?

Obviously, it costs money to create and launch a new app, but the cost to support the app over time is often ignored, undervalued or overlooked. These costs include:

· Software maintenance, whereby the developer proactively ensures the app continues to function correctly as new phone models and operating systems are annually updated and retired.

· Infrastructure costs such as Cloud-services (servers and storage) and other 3rd party add-ons such as notifications, map data, etc., that support the app and its users.

These are baseline non-negotiable costs that keep the app in tip-top shape.

Necessary funds for enhancing the app over time, as well as for marketing and so forth, are additional and comparably discretionary.

Considering this, it becomes immediately clear that a developer who charges a one-time fee will need to keep finding enough new customers to cover the cost of ongoing upkeep, while at the same time recovering their initial investment over some time horizon.

Alternatively, the subscription fee model provides economic relief by giving the developer a recurring revenue stream from existing customers and therefore a better chance at recovering their initial costs and the costs of maintaining the app over time. Or, in other words, it means the developer can sell fewer apps to break even or, keeping sales constant, have the additional revenue to apply to future app enhancements and marketing.

Which brings us to Apple. Putting any discussion aside on whether Apple needs help, encouraging a subscription model is smart business for very much the same arguments as they are for the developer. Apple hosts a very large and ever expanding online store of apps that costs a lot of money to run. If the developer is getting paid just once for their app, then so is Apple. If the developer has a subscription-based revenue, then so does Apple.

Note that Apple wants this enough to provide a concession to the developer by cutting their developer sales fee in half after the first year of a subscription, from 30% to 15%.

We believe, that encouraging subscriptions will help all participants in the long-term, will result in the continued improvement upon apps, new innovations in mobile solutions, and ultimately it will help ensure a rich ecosystem of apps remains available for everyone.

There are many historical reasons why app subscription has not happened sooner — at one point in-app purchases did not exist and a one-time payment was the only choice. However, the time for subscriptions to be promoted and adopted has come or, arguably, is well overdue.

Blue Rocket is a digital product development company based in San Francisco. Through strategy, design, and engineering, we help great companies build powerful digital experiences — the right way. Find us at www.bluerocket.us.

This article is an independent publication and has not been authorized, sponsored, or otherwise approved by Apple Inc.

Why Apple’s In-App Purchase Subscription Model Is Good For Everybody! was originally published in Blue Rocket Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to Accelerate Time to Revenue for New Mobile Product Development

What if I told you there was a way to get to market four months sooner and with a $380K USD savings? Would you be interested? If you are thinking of staffing new product development or innovation programs by hiring an internal team, this article is for you. Here is how you can accelerate your time to market and manage your capital more effectively. I’ll start this off by laying out the costs of staffing a new team and then discuss some even better alternatives. The examples are from the U.S. but are adaptable to most regions.

Costs of Hiring

It takes time and expense to hire a new product team. On average, it currently takes 38.6 working days to hire an IT professional, or about 54 calendar days. Remember, that is the average, representing the time to hire about half of your team. Let’s assume you’re fortunate and have the whole team hired within 71 calendar days.

There is additional delay between offer acceptance and when your new employees will show up to work. If you put that delay at 2 weeks, then it takes about 85 days to get your new hires in the door when no move is involved. If you’ve been involved in hiring, you know that this can take much longer for even a small team. After all, the average calendar time to hire a QA engineer is about 155 calendar days!

Recruiting new employees also represents a cost. A conservative estimate of recruiting cost is $22,562 using in-house recruiting, and $31,970 if you use an agency. Let’s say you need to hire a six-member team for your project, and you do it with internal recruiters… you will have to spend over $150K before the project even starts.

The Productivity Ramp

There is also a delay between the day that employees arrive on the job and when they are fully productive. When you hire designers and engineers, or any other team members for that matter, there is a productivity ramp. For example, when things are simple regarding the new hire’s role, organization, and product there is at least a month lost in ramp-up cost and time. For more complex scenarios, the estimates can rise to a full year. To stay on the optimistic side of this, let’s assume that the ramp up for your team is only eight weeks.

The productivity ramp not only causes delay, it also represents expense. You are on the hook for the salaries of all team members as they ramp. For example, let’s say that your six-person team averages a salary of $125K/year that translates to a fully loaded cost of at least $250K/year. For an eight-week ramp-up period you are out about $230K in ramp-up costs. These estimates are conservative… they reflect a context in which there is an existing team that can help bootstrap the new employees in relatively simple business contexts. The numbers will be worse for creating new businesses, new product lines, and innovation programs.

The Fractional Resource Challenge

If you hire for a new development program that is substantially different from your business-as-usual, you will be challenged to effectively use your whole team. Some team members will be slammed while others will only be needed for a fraction of their time.

Figure 1 lists 8 different skill-sets you will need to hire for a mobile solution. You will need even more skill sets if you still need to complete your market and consumer research and crystallize your business and product strategy.

Let’s say your plans pencil out to 4 developers for the project. You also need a designer. Companies have recently been increasing the number of designers per engineer. If you take the ratio of 1 designer per 8 engineers, then you will only be able to effectively use your designer on a half-time basis. The same is true for other roles.

There is inherent inefficiency in creating small new teams to staff new product development. This is why you see job postings that ask for skill sets that don’t exist… at least at the price that most companies are willing to pay. You’ve seen the posts, someone who is great coding the front end of the product, server-side development, is competent at visual design, design research, user experience, and can do software QA. Of course, a design portfolio and code samples are both required. It would be great hedge against the fractional resource challenge if you could find these people in a timely way. Unfortunately, you won’t.

The Net Costs of Building a New Team

The impact of building an internal team is non-trivial to new product development, especially where time to market and efficient use of capital are prized. Building a new team in our simple example will set back your launch by at least 4 months, and you will be out more than $380K. You will have accomplished nothing other than hiring and ramping your new employees with that investment. What is more, the team’s efficiency will suffer because of the fractional resource challenge. These are conservative numbers for a small team. In following this path, you will have blown some or all the budget and time required to get a first release of a product completed. You will also be anywhere from 50%-100% behind the schedule you could have achieved with outside resources.

A Better Way

That may all seem very heavy and discouraging, but you don’t have to settle for this. There are better ways to get a quality product into market quickly and at a reasonable cost than staffing from scratch. How you do it depends on two considerations.

• Are you committed in the long-run to the new product area you are pursuing, or does the business model and operating model still need to be validated in market?
• Are you committed to developing an internal core competency in this area of technology because you believe that this will provide a competitive advantage, and are you concerned about being dependent on external resources?

Let’s take on the first consideration. If you are not yet committed to the business area, product line, or innovation that you are pursuing you will save money, time, and organization stress by bringing on an external company to do your development.

When I took on an innovation team that was incubating new product areas, I asked my lead technical architect for his thoughts on how to staff development. He pleaded with me not to hire a development team but instead to rely on a top-end development company. His reasoning was that we would never attract (or keep) the same caliber of developer, that we could never keep them current in mobile and IoT technology, and that the last two times he had been down this path he had ultimately had to staff then lay off the development teams as the organization moved to different focus areas. Fortunately, I took his advice. You might justifiably protest that we would have needed the team had we stuck with the program we were bringing to market. It is a fair point but hold that thought so we can address how to do it while taking out time, cost and risk.

Now we’re ready to take on the second consideration. Let’s say you are certain that your organization is committed to the strategy and technology that you are working on and therefor you believe you must staff to have the capability you need in the long run. Your take is that the right team will give you the sustainable competitive advantage you need, and that you are committed to investing in them to keep them current. Are you stuck taking on the costs and delays associated with recruiting, ramping and dealing with uneven task loads? No, there is a much better way to make this happen.

Start by bringing on an on-shore or near-shore top development company so that you can get started immediately. Next, work out an agreement where your development partner brings on talent with the purpose of ultimately building out your team. You must do this in advance since many software-houses contractually prohibit you from poaching their talent. This way you know you have people who are a fit for the organization, understand the product and technology, and can deliver. You will avoid delays getting your product to market, minimize ramp costs, and you have no fractional resource challenge in the short term. In the long term you have a partner to provide part-time resources when they are needed.

Conclusion

Getting started in new business and technology area can be difficult, but you can remove much of the risk, delay and expense by finding the right partner for your initial releases. If you choose wisely, this partner can also help you with your ultimate staffing needs. Don’t get caught up in the assumption that you need to develop applications internally. Some of the most successful projects (e.g. Google, Groove, Slack) have started with external development teams for speed, efficiency, and expertise.

Blue Rocket is a digital product development company based in San Francisco. Through strategy, design, and engineering, we help great companies build powerful digital experiences — the right way. Find us at www.bluerocket.us.

How to Develop New Mobile Products Better, Faster and Cheaper was originally published in Blue Rocket Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here are some common reasons.

Lack of platform expertise

• Attempting to compete in a marketplace of tight well-crafted native apps without investing in platform expertise. Outcome: low adoption, critical reviews
• Relying on a business model that depends on tracking users across apps and devices. Outcome: app store rejection
• Attempting to market products in your app that you don’t sell through in-app purchase. Outcome: app store rejection

Lack of product focus or design thinking

• Failing to build your product around a clear value proposition that addresses a specific user type and user scenario. Outcome: scattered feature set, low adoption
• Substituting a wide feature set for a lack of clear value proposition that addresses a specific user type and user scenario. Outcome: low adoption, high cost
• Substituting glamorous visual design for a lack of clear value proposition that addresses a specific user type and user scenario. Outcome: low adoption, high cost

Lack of software engineering expertise

• Failing to recognize that early product development is a rare skill that most software professionals never get the chance to acquire. Most programming careers are spent enhancing and maintaining existing products. Very few engineers spend significant time starting from zero on a new product. Outcome: late market entry, poor team morale, buggy app
• Failing to optimize content and content delivery to mobile screens and mobile network connections. Outcomes: poor responsiveness, critical reviews, low engagement
• Failing to recognize the wide set of skills necessary to bring a new product to market. Asking developers to build without clear design, designing without reference to technical feasibility, ignoring the necessity of expert quality assurance, expecting developers to exhibit emergent behavior like a school of fish or flock of birds with no hand on the helm. Outcome: a product that never reaches market readiness
• Failing to adequately instrument the application with runtime feedback loops for usage, critical bugs and user opinions. (Flurry, MixPanel, GA, Crashlytics, etc.) Outcome: reliance on guesswork to inform next steps.
• Assembling a team of people who have never before worked together and expecting them to deliver on technology they have never before built. Outcome: failure to launch

Lack of business maturity

• Failure to provide a user acquisition strategy. Ignoring the need for some mechanism beyond word of mouth to fuel discovery and growth. Outcome: low adoption
• Failure to provide an engagement strategy. Addressing one user scenario that brings a user to your app initially but never brings them back. Outcome: high download/open ratio
• Build your customer-facing product before nailing down your core invention. Outcome: high cost, failure to launch
• Failure to recognize that new technologies, new target devices, unknown teams and nascent product-market fit already reduce the odds of success too far to add language barriers, time zone synchronization and lack of shared incentives. Outcome: failure to launch

Blue Rocket is a mobile product development company based in San Francisco. Through strategy, design, and engineering, we help great companies built powerful digital experiences — the right way. Find us at bluerocket.us

Failure to Launch was originally published in Blue Rocket Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

The appropriate commitment to design varies widely, but there is a discernible pattern. The right answer depends largely on the role design plays in your app’s differentiation. Overspending on design, especially on your initial release, lowers your ability to execute and your ability to iterate. Underspending increases the risk that you will miss product market fit and increases the risk of losing users too quickly to iterate toward tighter fit.

One way to break down the problem is to look at what type of design effect you need to complement the app functionality. Four levels of effect are listed below:

Four Levels of Design Effect

Reading the Chart

We plot benefit against effort. For example, if your app requires a natural level of design, you will reach maximum benefit expending 10–20% of your initial budget on UI/UX design and research. Think of user loyalty, sometimes measured as Net Promoter Score, as a relevant design benefit.

Functional

The lightest level is best described as functional. You may find that the app’s screen flow and layout closely map to the underlying database tables. You may devote little care or attention to usability and polish. Succeeding with such an app requires a captive audience. An audience might be captive because of:

· An internal app — Users are employees of the app publisher.

· A small audience — The app solves an important problem that relatively few people experience.

· A high enclosure — The app is not the user’s chief motivation for giving this company his custom.

Natural

If you are determined to zero in on the true value proposition for your users, you may allocate more research effort. When you care about retention, you will devote effort to designing the user’s simplest path from beginning to end. When you apply this level of design, the resulting app will be:

· Simple — For example, such an app might not require first run tutorials as the UI itself provides clear, well-reasoned defaults and limits the number of choices available on any one screen.

· Thoughtful — Designers of such apps frequently devote considerable thought to how the app will react to external stimuli, for example, how the app will perform when the users task-switch back and forth, to and from other apps.

· Familiar — The designer will pay close attention to platform-specific controls, gestures, layout and navigation conventions. Leveraging such idioms avoids placing the user under heavy cognitive load and allows them to focus on the app-specific task versus learning new conventions.

Magical

Some apps make it possible to do things that seem like magic. At this level, your users may see your app as:

· Omniscient — Using new sources of data (e.g. crowd-sourced data) to provide insights into questions that previously seemed intractable to your users.

· Effortless — Completing tasks in one step (or a few) that previously required your users to perform multiple steps across multiple systems (often depends on integration of back-end systems).

· Proprioceptive — Capturing ambient data through onboard sensors to discern location, proximity, movement, environmental factors, etc.

· Hyper-observant — Recording your user’s previous choices and behaviors in order to anticipate their needs and create deft personal defaults.

High Gloss

Other apps are differentiated based on beauty and level of polish. They are frequently:

· Skeuomorphic — Possessing an interface that mimics real-world counterparts in appearance and/or interaction

· Photogenic — Emphasizing the use of photographic elements.

· Heavily customized — Requiring invention of new user interface conventions or components.

This level of finish seldom makes sense for a first-mover, as finding product-market fit is difficult by itself and frequently requires several iterations. This is particularly true as such iterations are much slower and more expensive, since each new direction has to be re-polished to a high gloss. This level of finish is more appropriate in a high-value, hotly contested market where the user is extra sensitive to aesthetics (e.g. cosmetics or fashion).

Choosing the right level

Once you recognize which level of design finish suits your app, you will be better equipped to prepare a budget for the product build. It is crucial to do so early, as the wrong decision is always a costly one. Some of the factors that affect your choice of design finish are:

· Subject Matter

· Audience

· Market Maturity

· Value Proposition

· Budget

In our next post on this topic we will consider how some of these factors affect your choice of design finish level.

Blue Rocket is a mobile product development company based in San Francisco. Through strategy, design, and engineering, we help great companies built powerful digital experiences — the right way. Find us at bluerocket.us

Right-sizing Mobile App Design was originally published in Blue Rocket Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most Innovations Succeed or Fail in Execution

At a recent innovation conference, a speaker asked how many of the 75 people present in the room were short on promising ideas to implement. One person raised their hand. When asked how many struggled with execution of their best ideas, up went most of the hands in the room. A couple of months later I asked a colleague doing innovation for a large enterprise what kept him up at night. His answer: “All of these great ideas and they just don’t seem to go anywhere”.

The Front-End Matters, But Leading Change is Critical

Sure, there is ample research to show that an empathetic understanding of customer needs, and the use of those insights is essential to success (1, 2). But that is only a start. Years ago, I sat down with the executive leading an innovation organization for a Fortune 100 company and suggested we amp up the change leadership skills in the group. She looked at me for a second, paused, and asked… “I don’t understand, why would we do that?”. The organization was gone within a year.

The simple answer to her question is that innovation requires organizations and their people to do new and different things to execute clever ideas. Further, to succeed at influencing organizations to do new things requires that you ensure the skills, motivation, and confidence to win are in place. A recent HBR article (3) identifies the transition from the innovation or R&D lab to the operation as the phase in which most innovations die. Your idea may be just fine, but the ability to engage your organization to execute the idea is likely to need more attention. This is much more than selling the board. You must understand your whole solution and the implications of executing it.

Succesful Innovation Requires Change on Multiple Dimensions

All you need to do is to take a tour of innovation research and the need to master new ways of doing business becomes clear.

In his book “Ten Types of Innovation” (4) Larry Keeley describes research with his colleague Vijay Kumar. They compared organizations that were “average innovators” with those that were “top innovators”. What they found was that the top-innovating companies innovated across more dimensions of their product and business system than did the rest. Moreover, the number of distinct types of innovations companies used was correlated with their overall financial performance. They lay out 10 types of innovation from internally focused dimensions like profit model to externally focused dimensions like customer engagement (see sidebar).

Keeley’s research suggests that you most innovate across at least 2–5 dimensions of the overall business system to be likely to succeed. How many depends on the magnitude of disruption you are targeting. For example, you might need to innovate your product, your distribution channel, and your profit model — perhaps more. No wonder big innovation is hard, especially for big companies. You must orchestrate simultaneous change across multiple parts of your business system. Do you have the pull to create a new distribution channel for your products? Can you manage the potential for resulting channel conflict? The same goes for business models. If you’re a product company moving to a service model or subscription model you not only have to collect money differently, but the change must ripple through your accounting and forecasting systems.

Use Functions As-Is, Adapt, or Create

One of the most consequential choices you will make as an innovator is whether you can operationalize your product through existing functions, whether you need to convince one or more function owners to adapt to your innovation, or whether you must create a new function. Hopefully, you can use some of your organizations operations as is. However, each type of innovation you pursue will require you to trace the execution of that innovation through your existing business system to identify the required changes and additions. Will the function owner be willing to change it? What is in it for her? At a minimum you are offering risk… what else have you got to offer? If the function is a cost center how will any increased costs be made up in her budget?

Sometimes, it is not feasible to create a viable value proposition for function leaders, or it just doesn’t make business sense for them to create the modifications you seek. In these scenarios you need to build a parallel or add-on function.

Let me share an example of where I got this all wrong. I was working on setting up the execution of a digital innovation in a big company. The product was a great idea, well received by consumers, and would benefit the business. What could go wrong?

I chose to use the central IT organization to create the mobile infrastructure, application, and integrate with server-side functions. I liked the team, it’s leaders, and really liked the idea of forging a relationship between our two groups. Here is the problem. Most large IT organizations do not build bleeding edge consumer digital products all day every day. They either must train or staff to be able to adapt. In most enterprises it is very difficult for teams to keep up with recent technologies, platforms, and frameworks. Often these developers go from internal systems to external systems as assignments change, sometimes over the course of many months or even years forever keeping them in catch-up mode. Furthermore, they will have priorities and motivations that are quite separate from your project.

After a year of attempting to execute this way I changed course and brought in a top-notch mobile development house. They worked at a completely different clock speed and with a risk tolerance that matched the project. Within 3 months we had made up the lost time.

One caveat to this approach is that you must maintain architects who understand your legacy systems as part of your program, especially when you need to bring in outside talent. External teams or new employees will have no familiarity with how to work around legacy systems. In a future post, we will break down the cost-benefit of outsourcing (onshore) vs. ramping up an internal team.

It turns out that the path I was on with my IT group is a crowded one. When queried about the biggest challenges facing product and marketing executives working in the connected home space the top challenge they identified (59% of them) was building the application. Yet, more than three quarters of them continue to plan to build internally (5).

When You Must Walk Away

Sometimes there is no way to execute a promising idea from your organization. The sooner you recognize this and walk away, the better. If your solution requires digital marketing to succeed and your current marketing department doesn’t do this, it is time to pause. Can you incent them to ramp up or support you sourcing that function in parallel? If not, walk away.

What if you are an insurance company that distributes through independent agents? This is a channel that is tuned for a very specific type of product and may simply not be adaptable to your new solution like selling widgets or car safety kits. Agents are paid for policies. If you are asking them to do something that does not help sell more and bigger policies faster or threatens their relationship with their client, you may not get much traction. This is the choice point. Do you have the flexibility to create an alternative channel? If not, walk away.

Are you thinking that in these examples you should just enlist the most influential executive you can find to force the issue? It might be worth exploring with the right executive, but generally this is not a great plan. It will isolate your team and create compliance with low motivation. Even worse, it makes your organization more fragile. When that executive ultimately leaves, you’ve got problems.

How to Become an Execution Wizard

Don’t let the challenges of execution scare you off. Some of us thrive on this stuff, and you may too. Here are three essential steps on the path to becoming an execution wizard:

• Engage cross functional teams in your investigations (6). Bringing in good minds from across your business system makes you more effective at identifying more types of innovation to pursue. A multi-disciplinary team is also more likely to identify the implications of your innovations to the operation. They can work with you on ways to design effective solutions and test them. Just as important, they become advocates to work through resistance to change.
• Provide innovation discipline across the business system. Systematically target your types of innovation, then trace them through your business system. Identify your areas of risk, then prototype test and refine each of these areas just as you would your core product. This step is critical for two reasons. First, it enables you to remove risk from the program sooner and enables you to design how your program will be implemented well before you start implementation. Second, it will enable you to identify problems that are insurmountable sooner, triggering you to pivot or move on much sooner than you would otherwise.
• Engage executives. Top executives often play a key role in innovation programs (6). It isn’t just about keeping your hand in their wallet. It’s about tapping their expertise on how to engage and connect with the wider business system. As they consider some of the concepts you are pursuing their view across the business enables them to identify key people and functions that you will need to work with. If you need to build out new parts of a business system, your top executives and boards can provide invaluable help sourcing it with their wide business networks.

The Execution Challenge Is Worth It

Throughout this post you have seen how successful innovation requires embracing complexity. You must lead change, you must innovate across multiple dimensions of your business, and you must orchestrate a new or modified business system. The good news is that this complexity brings two great rewards. The first is that it provides a barrier to your competition. The more dimensions on which you innovate, the harder it is for others to understand and copy what you have done. The second is that systematically innovating across your business system greatly increases your chances of success.

(1) Ottum, B., Moore, D., 1997; The Role of Market Information in New Product Success/Failure. Journal of Product Innovation Management, Volume 14, Issue 4.

(2) Bacon, G., Beckman, S., Mowry, D., Wilson, E. 1994; Managing Product Definition in High-Technology Industries: A Pilot Study. California Management Review, Spring.

(3) Kirstner, S. 2017; The Stage Where Most Innovation Projects Fail. Harvard Business Review, April 11, 2017.

(4) Keeley, L., Pikkel, B, Walters, H. 2013; The 10 types of Innovation The Discipline of Building Breakthroughs. Wiley.

(5) Taylor, W. 2017; 2017 Survey of Connected Home Product Professionals. White paper downloadable at: https://www.bluerocket.us/build-it-right/.

(6) Cooper, R. 1999; Invisible Success Factors in Product Innovation. The Journal of Product Innovation Management. Volume 16, Issue 2.

Blue Rocket is a digital product development company based in San Francisco. Through strategy, design, and engineering, we help great companies build powerful digital experiences — the right way. Find us at www.bluerocket.us

Why Execution Makes or Breaks Innovation was originally published in Blue Rocket Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.