Blog SEO: 5 Simple Techniques to Start Doing Now

1 – Easy-to-Read urls

Use urls that indicate the subject of each post, not numbers. Deep-linking (linking straight to a page) may be bad for security on some portals or throw off your conversion funnel analytics in commerce, but a blog should represent an interrelated series of ideas.

Pro Tip: This probably makes your urls so long that they are hard to properly Tweet. In Social Media, use Buffer, Hootsuite, or SproutSocial to shorten the url and auto-schedule the timing of your post.

 

2 – Link to Your Old Posts

Anytime you write a new post, think of how it relates to at least one previous post you’ve written, and link to the previous post within the new post. This means you need to know your blog contents. It is nice that a Blog can let you explore new topics on the tangents of your profession, but if you can’t create some sort of emergent cohesion, no reader and no bot or spider will do it for you.

Pro Tip – If you are a member of a team that manage a blog with a TON of posts, read a new post from months or years ago each day. React to it, link to it, write about it.

 

3 – Link to Your New Post

Anytime you add a new post, find an old post that is related and insert a link to it. The easiest way to do this, naturally, is to use the post you linked in #2. It will be better for your readers if there is a logical place to include it within the content of the previous post, but adding a “Recommended reading” section at the end of a post can help as well.

4 – Tags and Images

The easy thing here is to make sure you start naming any images so that they have meaning independent of the image. Using headers to organize the content of a post should be a no-brainer as well. If you’re bootstrapping and crunched for time – its never too late to start doing it better going forward with more discipline. If you’re a big business with a massive site, an SEO consultant who can dive into your code is a useful ally.  What may not realize is most SEO experts will give you a fair amount of information for free. Just ask!

5 – Have Fun!

Okay but seriously, the most important thing that will improve your SEO is to create content you care about. Take pride in the topic. Take the discussion with you into the real world. If the blog is an authentic “shadow” of who you are or who your organization strives to be, people will find it interesting. Find interest groups on Twitter and Snapchat and LinkedIn – then CARE. If you don’t care about your craft, no one will. If you don’t love blogging about your craft, no one will care about your blog.

You Look Dumb – 5 Mobile Marketing Mistakes

Your smart presence looks pretty dumb.

Welcome to the “smart” era – smart phones, smart cars, and smart homes are finally here! You can officially go to display rooms in your local appliance store instead of booking a trip to Orlando to see the home of “the future”.  In our smart era, a fair percentage of the population now carries supercomputers in our pockets with computing power that would have filled a warehouse even in science fiction during the baby boom.

Unfortunately, as “smart” as all this technology should be in your business, I’ve noticed your company looks pretty “dumb” because things are getting done exactly the way they were before, but now on a smaller screen!   As much as technophiles may blame late-adopters for not buying in to new devices and new apps, wake up – if you’re asking people to do the same old story, same old song and dance, but you’ve given them a more difficult form factor to do it on, they have no reason to adopt!

In that light, here are the 6 mobility mistakes you might be making RIGHT NOW that keep your mobile presence looking dumb where it ought to be smart:

 

#1 – You Encourage Channel Hopping

If your mobile marketing strategy has shifted consumers from one conversion funnel (web or brick) to another (apps) but hasn’t resulted in increased revenue, you’ve encouraged channel hopping.  This is a nightmare scenario that often pits employees of each channel against each other internally, fighting for additional budget, unable to fully justify forecasted ROI.  What happened? When you built your native app, the value created by your investment was captured 100% by your consumers!

This looks dumb to the smart consumer, because it is painfully obvious when the only difference between the native app and the responsive site is Touch ID. The choice between a link on the home screen versus a downloaded app comes down to space on the phone and speed of content loading.

The math for the mobile marketing individual is so simple that this mistake looks extra “dumb” to your boss. When traffic stays constant, but an additional channel is added, aggregate conversion across the channels must increase or else your funnels are just cannibalizing each other. That’s the ROI problem every mobile marketing initiative must overcome: when you invest $200k in mobile eCommerce and revenue stays constant, your consumers have captured all the value created. Sure, they may be happier. They might say “how convenient to have a desktop site AND an app for researching and executing my purchases!” Unfortunately, the return on your investment they capture doesn’t inherently result in more traffic, conversion, sales, or loyalty.

Admittedly, companies don’t make this mistake in a vacuum. They see traffic and sales moving from their desktop site to a new competitor’s mobile app – panic ensues – and they build an app of their own to stop the bleeding.

Remember, a bad bandage can be more dangerous than no treatment at all. The smart mobile marketing plan requires one of two approaches to respond to the threat of new entrants:

  1. Double-down on web. Yes, I make mobile apps and I’m saying its okay not to have a (native-coded) mobile app. If your plan for mobile is to reproduce a brochure, a paper form, or a website, don’t do it. Seriously, just throw your money in a pile and set it on fire like the Joker in Dark Knight.  If your site is working great but it isn’t a responsive site – start there. If it is outdated and anything is unintuitive, fix it. If you can’t create a unique relationship with consumers through your native mobile presence or capture the channel-specific value created, double-down on making your web presence best-in-class. This is Game Theory 101 – If you can’t win at both web and mobile, win big at one and forget the other.
  2. Create a unique market via app(s). If your audience is shrinking or your relationship with your consumers is suffering due to the mobile presence of a competitor and a truly unique relationship can be built through a mobile app – do it. This means your mobile presence needs to accomplish at least one of two things: augment the physical experience in ways a website can’t (to increase conversion) or create a completely new experience for a totally new audience (to increase aggregate traffic). Which path is right for you will depend on your market, products, and competitive landscape – so do your homework (and get a “tutor” as needed).

 

#2 – No Context Awareness

This is at the heart of what is so dumb about the way many companies establish a market presence on smart devices. If you have the opportunity to look “behind the curtain” you will notice this problem is not isolated, but occur on two fronts for that firm – externally in their consumer native apps and internally in their custom enterprise solutions. I’ve touched on specifics of Context Awareness several times. The differentiating power of a native app is in its intimate knowledge of where a user is, where they are going, and how they think. Segmented push messaging, one-tap deep-linking, and social API integration make the native app capable of a completely new relationship with your consumer. They are using a supercomputer that aggregates an unprecedented amount of personal information – all you have to do is offer a reward that justifies opting in.

Don’t fall prey to the opposite though – opting out should be easy, transparency on the use of private data is key, and you typically have one “strike” per consumer when it comes to keeping an app on their device. Whether it is download size, loading time, or privacy betrayal, as W.B. Yeats wrote, “Tread softly because you tread on my dreams.”

Talk to technology professionals so you don’t plan your mobile presence in a vacuum. Geofences, iBeacons, IoT hardware, Photos integration, BLE, IoT, QR, wearables, and triggered messaging are all tools of the trade for ensuring you are able to create a unique proposition in a native app. Find the biggest impediment to solving your consumer’s pain in a way they will pay money for you to solve. Do NOT invest in native mobile unless the pocket supercomputer is going to augment physical realities with digital awesomeness.

 

#3 – No Business Intelligence

Ignorance is bliss. Unless you are driving a drastic paradigmatic shift in how you engage fresh generations of consumers through a new and constantly-evolving medium. In that scenario, ignorance is death – the death of any success you could have achieved.

“No Business Intelligence” is the bad-joke-telling best friend of “No Context Awareness” who crashes the wedding reception of your otherwise-integrated-marketing strategy. Where context awareness can drive new forms of engagement by proactively anticipating needs and supplying easy answers, business intelligence is a trailing ROI that takes effort to reap.   Business Intelligence is like planting a vegetable garden, as much as the visual presence of a lovely variety of plants may have delighted you on its own, you are leaving ROI out in the field until you harvest it. The same is true in mobile marketing. Until the big data you have created is collected, curated, and learned from in order to provide better plans, more focused campaigns, and the tightest possible updates to forecasts, you are creating white noise that should have been a joyful symphony.

At a minimum, it is essential you collect enough meaningful data to justify that you have accomplished your goals. The less you can prove directly that you have created new traffic, new converted sales, or new revenue sufficient to justify your investment in mobility, the more you need business intelligence to prove the indirect benefit provided to other channels. Better yet, even when new revenue is both directly and indirectly attributable to your mobile presence, you should drive BI insights like you are starting a company that will sell its knowledge. You may start by “selling” it internally to help justify you P&L, but don’t rule out the possibility external buyers may exist.

 

#4 – No Game Plan for IoT

If you don’t have concrete plans for drone technology or self-driven cars, I forgive you.  Not every industry will need direct adoption for these new technologies.  However, if you haven’t given serious thought to what your products and services can be in a connected world – called the “Internet of Things” – you are going to find yourself left behind over the next five years.

IoT is already within reach and less cost prohibitive than you may think. Connected power indicators, pipe flow sensors, BLE chipsets for detecting and communicating almost anything – they are all out there. Today what is being “tacked on” to products by R&D will tomorrow be a seamless experience seen as the baseline for market entry. You can afford not to be the first mover to the extent Silicon Valley startups are learning the hard lessons for us all today. That said, don’t get out of touch and don’t get left behind.

The Internet of most connected Things means at least one of two potential realities your business:

  1. Some products you currently market “dumb” will be expected to connect soon – a significant event in your product strategy because the value proposition of your physical Thing will not matter as much as how it connects to the app you provide with it. Think today what that app must be in order to compete. In fact, you should probably be building that app instead of reproducing your already-responsive web site. Then, more dauntingly, think about that product and app and their ability to connect with other Things that are connected in a way that creates a meaningful brand relationship.
  2. Widespread IoT products will further segment your target market and the position of players across your competitive landscape. If your product’s three year plan does not clearly indicate whether you will focus on selling non-connected versus connected variations or both, including the business case for how each will be priced and marketed, schedule meetings right now to drive those discussions.   The threat of new entrants on both sides will be higher as major players struggle to straddle the fence strategically.

 

 

#5 – You’re Stuck in Analysis Paralysis

Speaking of sitting permanently on the strategic fence, one of the dumbest responses to the introduction of smart technology is analysis paralysis. As my strategy professor emphasized while introducing Michael Porter, refusing to make a decision is your decision. That favorite Porter quote – “Strategy is the art of making choices”. In a Zero Sum game with multiple players and finite economic resources, strategy is the art of committing not only specific resources, but also commitments as a competitive position to the long-term continued investment of resources. By holding resources – even in the most uncertain times – you’ve made a decision to wait. The key to the good life, as Aristotle would say, is that the decision to wait, if virtuous, must intrinsically be deliberately decided.

If your organization is stuck in analysis paralysis, overwhelmed by the amount of aging IT investments behind you and the mountain of new (and sometimes unproven) technology ahead of you, a lack of action may preserve some capital in the short-term, but you are racking up immense opportunity cost and learning curve disadvantage. If your company has too many ideas and no commitment to a roadmap, here is how to get smart:

  1. LESS IS MORE – Don’t try to reinvent your entire IT and Marketing infrastructure in one big push. Define Lean Startup-style MVPs that give you a “quick win” (or a few) while getting you past the rookie mistakes, first-time jitters, and growing pains that are inevitable out of the gate.
  2. SOLVE REAL PAINS – Mobile for the sake of mobile fails the stakeholder, the end user, and leaves a bad taste in the mouth of executives and investors. Look for the biggest complaint of your customers or the biggest inefficiency in your operations workflow. If the solution is mobile, do the smallest possible iteration of that solution. If it isn’t mobile, fix the pain without mobile. Rinse and repeat as needed.
  3. OFF-THE-SHELF is an OKAY START– On that note, with the thousands of tech companies out there, don’t go custom on everything. Open or paid APIs, packaged solutions, and white-label solutions, and SDKs are all alternatives to re-inventing the wheel in a vacuum. Review your options carefully (but keep the scope of your goals tight enough your review doesn’t paralyze you).

Disrupt & Win: Next-Level Lean Process Improvement

Disrupt & Win: How to Achieve Next-Level Lean Process Improvements with Custom Apps

Is your business having trouble keeping up?

It is time to get lean.

Kaizen – Continuous Improvement

Kaizen is a core principle from Lean that lays the foundation of how we choose the right custom enterprise mobile and web apps for process improvement efforts.  Loosely translated from Japanese, kaizen means “change for the better”; but kaizen is bigger and bolder than tacking on an improvement to an existing structure – it is the process of continuously breaking down a process, removing unnecessary effort or waste, and rebuilding it as a more efficient and effective process.

In custom enterprise app consulting, kaizen is the ultimate goal of the discovery and analysis we follow in finding the key enterprise workflow that is both proprietary to an organization’s competitive advantage while (sometimes surprisingly) it is also a source of pain and waste.  Because this seems contradictory, companies rarely ask for the application that will make the biggest difference to their organization.  To plan a truly disruptive roadmap that will position your key processes for sustainable competitive advantage takes a level of honesty and vision that is not easy to tackle alone.   Here are some key concepts from Lean that we use to help you plan your enterprise app portfolio and take your kaizen to a whole new level.


The Three Actuals – Genba, Genbutsu, Genjitsu

Lean consulting begins with finding the 3 Gen or “actuals” of your enterprise.  Kaizen is impossible without direct insight into the organization, so these three “actuals” are critical to finding the right apps that can succeed big and drive the adoption of innovation and mobility as a competitive strategy:

  1. The Genba – By visiting the Genba or “Actual Place” where business is done, products are built, and revenue is generated, an enterprise solutions consultant can view and understand the operations that create value, whether in a factory, a medical facility, or a sales showroom.  Through first-hand observation, rather than conversation, far more can be learned about what an organization does, how it is done, and why it is done.  Whiteboards and conference calls can never convey the real heart of an enterprise, the “What’s the point?” or the “What’s it worth?” as it is experienced by the people who keep each process moving, so coming to the actual place is critical to building out a solution that speaks to the pain felt by the people performing the work.  These pains tend to originate from inefficiencies and information asymmetries that workers will protect out of a fear of change.  Changing a process through training or a set of new rules often fails for this reason.  The disruptive influence of a mobile solution shortcuts this fear – mobile adoption rates are accelerating and new generations of employees demand the simplicity and focus of apps in the workplace.  These employees must capture real value in order to drive higher revenue and operational cost savings – getting to know their daily workplace experience is crucial.
  2. The Genbutsu – If possible, a great consultant doesn’t just watch, it is even better to directly interact with the genbutsu or “Actual Thing” – the real equipment being moved throughout a hospital or the customer “hand-off” artifacts.  In Lean Manufacturing, this often focused on the actual parts being assembled, the path those parts travel in a factory, and finding ways to simplify repetitive motions, reduce unnecessary travel distances through better placement of the work stations, or reducing the complexity of a step in the process by changing the order in which pieces were added to the final product.  In enterprise mobile solutions the “actual thing” is often information and the path it takes before and after that information becomes data and drives actions that produce revenue.  Information is easily decontextualized, so minimizing context-switching in the information-data-action flow is critical.  Mobile solutions drive context-awareness that turns social information into actionable data immediately and cuts out waste.
  3. The Genjitsu – Jitsu is an art, skill, or practice; a word that evolved etymologically from the characters meaning “a step along the middle of a road”.   In Lean consulting, this means we must grasp and communicate the “actual situation” as it pertains to one process as a step in an overall flow.  More importantly, we must quantify the reality of the process as objectively as possible, separate from emotional responses due to ego, social status in the organization, or feelings of blame.  We do this by obtaining data, making hypotheses, documenting workflows, and validating assumptions.  The goal is to not only make a well-informed decision about the most valuable apps that can be created, but to validate the features that will be part of it.

Once the three “actuals” are known, sources of waste can be objectively identified, solutions crafted and prioritized, and an initial Minimum Viable Product can be determined.  First, let’s review how we can create custom apps using proven Lean process improvement tactics.


Just In Time – Why mobile?

Mobile apps are fundamentally on-the-go and on-demand.  The instantaneous nature of communication using mobile allows the Just-in-Time management philosophy  to apply to operations processes, delaying resource commitment and investment until it is absolutely necessary.  This allows the shortest possible feedback cycle between demand and supply and removes waste due to information asymmetry.  If you have ever been left alone as a sales rep checks inventory or watched someone wait on hold to obtain manager approval, you know you know how painful – for the employee and the consumer – a lack of instantaneous information-data-action can be.

Just-in-Time is well defined by its original proponent, the Toyota Production System:

Supplying “what is needed, when it is needed, and in the amount needed” according to this production plan can eliminate waste, inconsistencies, and unreasonable requirements, resulting in improved productivity.

via Toyota

Since our app strategy is founded on upgrading key resources by removing wasted time and effort, mitigating inconsistent process throughput and output, and unreasonable rules and requirements to “protect” against costly mistakes, Just-in-Time is central to every great enterprise app portfolio.  Social information becomes actionable data, from answering time-sensitive questions to triggering purchases.  Real-time communication can replace unnecessary meetings, a highly focused and intuitive user experience can replace training memorization of rules.  The ability to ignite a chain reaction from 3 taps of an iPad is an incredible time and cost saving that can also create enormous additional value that can be captured more quickly.

Implementing Just-in-Time through custom apps allows real-time analytics about the process and its evolution, a “version history” for process improvements, gamification of as-you-work training, and a real-time feedback system for future kaizen.  This means creating continuous flow, level-loading process steps, creating “smart” tools, standardizing quality of work, and balancing minimal investment against highest value productivity is not only simplified, it is easy to validate process impact quickly.


The Yamazumi Board – Creating Continuous Flow

The first step in improving a process with one or more apps is documenting the existing workflows as the focal point of discussion and as the baseline for hypotheses about potential improvements.  There are software tools for this, but post-it notes on a whiteboard can work as well.  Yamazumi literally means “to pile in heaps” and this is exactly what how the analysis is completed, by stacking each step in a process in columns representing each person or role in the workflow.  This could be fairly high-level, tracking the flow of a paper form across the organization, or extremely granular, such as every step in the manufacturing and assembly of a complex product.

via Michel Baudin

By documenting the steps of a process in this way we can easily visualize the imbalances in a workflow, identify the “pace maker” process, discover bottlenecks, and clearly see the cost of unproductive downtimes.  Combining roles that cause diffusion of responsibility, separating roles that cause unnecessary task switching, and removing unnecessary “fail-safe” measures will remove waste and reduce cycle time, making the process more efficient overall.

Once each process in the workflow is organized into an ideal future state on the yamazumi board, we can easily see the specific tool each role will need to be as effective as possible at creating value.  If each tool has a unique user base, we will consider each tool a separate app that we can evaluate and prioritize based on expected returns.  Next we evaluate how strategic disruption using a mobile-first mentality will create impact above and beyond simply reorganizing existing resources.  Whether we are targeting information, inventory management, or customer interaction, our app portfolio needs to work as a seamless ecosystem that facilitates continuous flow across the entire value stream.  Through notifications, context awareness, and on-the-go data connectivity, we are able to brainstorm solutions to each identified pain that can achieve heijunka.

Heijunka – Level Loading

The Lean Lexicon, 4th Edition defines heijunka as:

Heijunka is leveling the type and quantity of production over a fixed period of time. This enables production to efficiently meet customer demands while avoiding batching and results in minimum inventories, capital costs, manpower, and production lead time through the whole value stream.

Once we have seen how our piles of work are should be distributed to achieve continuous flow we then need to identify the pains and inefficiencies that exist even when the process is running smoothly.  Before we can prioritize a roadmap of custom mobile apps, it is important to know the elements of a process that are consuming unnecessary time and resources, find and remove batch-and-queue systems that create process bottle necks, and smooth out supply and demand.  Because we have distributed process steps across focused roles using the yamazumi board, we can now look at the specific pain points that each tool can address for each role.

In Lean Manufacturing, the concept of heijunka is taught using forecasting in supply chain management.  The more unpredictable the demand, the more advanced the forecasting algorithm may be but delaying differentiation, stabilizing production, and reducing inventory holding costs is always possible.  When creating disruptive-grade process improvement with custom mobile apps we can apply the same principles to “memes” and look for the inefficiencies, loss of fidelity, and bottle necks in processes that transform context-specific social information into data that is actionable across multiple roles.  To win at disruption and to resolve internal information asymmetries and bottlenecks, we need to think through solutions that remove the noise from the signals we rely on to forecast processes.  To this, we use custom apps to control selection, throughput, and output.


Jidoka – Autonomation

From the Toyota Production System, the concept of jidoka – “automation with a human touch” means that machines are “smart” enough to identify their own failure, empowering human operators to rectify the problem before faulty parts enter the production line.  Before autonomation these parts were only tested at the end of the production line, so a single machine creating bolts for engines could make an entire day’s work unsuitable to ship!  To mitigate the immense risk of an entire factory-day’s production being scrapped, an operator could be placed at each machine, checking quality of output at regular intervals.  Jidoka is the next evolution of this process improvement, so that machines judge their own quality and a single operator is able to validate the accuracy and quality of several machines, reducing the number of resources required per machine.

In an enterprise app portfolio, the ability to focus a user on completing a single workflow quickly with context-based help and input validation accomplishes similar autonomation.  The more focused an app is on a single user completing a specific task, the less we will need restricted access and complex logic.  Instead, the technological investment can be focused on context awareness and assistance.  This creates a powerful ability to the guide subjective observation of an employee into objective judgment.  Rather than increasing training, creating new policies and punishments, and increasing managerial oversight – an a attempt at a “fail-safe” environment – we want to create intuitive “smart” solutions that create a “safe-to-fail” environment in which some mistakes are no longer possible and consequences are minimized.  This empowers employees to consistently succeed and removes the stress of failure, all while reducing the need for direct managerial oversight and human approval processes.  Anywhere your employee is asked to supply critical information or responsible for continuous flow to the next process step, we want to facilitate responsiveness and guided interaction, then capture and aggregate data as Business Intelligence that can inform both the worker and organization leadership about decisions being made.  Anywhere an employee must manage machines or technology, the inner working of which only a specialist would understand, we want to create an interface into the health of the process rather than set the false expectation that every employee can be skilled at

Once the solutions to process pain and waste are imagined – with an eye on “smart”, intuitive mobile workflow tools – we want to look for ways to ensure that throughput and output are consistent in time, effort, and quality.


Standard Work

Through effective information architecture and user experience design, the mobile app user is able to follow an established and intuitive workflow of interactions that are ideally context-aware.  So in addition to the focus, empowerment, and autonomation improvements, going mobile is a time to analyze current best demonstrated practices internally and externally, and standardize them.  Standardizing what is done, how it is done, and creating consistency of output not only reduces the necessity of identifying and addressing under-performers, it creates a context for the employee in which output quality is held constant for them, enabling focus on critical thinking and social engagement rather than policies and spreadsheet-like information tables.  Even more importantly, once work is standardized with a mobile application (e.g. instead of a document template) the consistency of output and capture of Business Intelligence will allow an objective review of “best” practices, assist with hypothesis and experimentation removing some of the emotion and politics from the kaizen process.

Once changes are identified, effective MDM enables your organization to control the shift to a more effective practice by simply releasing a new version of the software.  Build any training (using interstitial screens) and feedback (with modal per-feature ratings) directly into the application.


Minimum Viable Product

The end goal of removing interruptions to continuous flow, level-loading processes against fluctuations in supply and demand, and removing information asymmetries and process waste is to attain Minimum Viable Production – a process state in which we find a “sweet spot” in the tension between minimizing invested value while maximizing return on that investment.

This goal will need to be reached on three levels:  the process being improved upon, investment in improving the process, and prioritization of the custom app investment portfolio.  Because we are disruptively and potentially drastically rebuilding a process we need to understand the point of diminishing marginal utility for inputs to the process itself as a precursor to determining the investment we should make in it.  If we are attempting to increase revenue through an improved sales representative process, we need to recognize that increased capacity does not increase demand – we will need to identify stabilizing and increasing supply can result in an unfair advantage in the market.  If demand for a process output is unlikely to grow, investing in increased capacity is ill-advised.

If we focused purely on minimalist production, we would drastically rebuild our core operations processes – stripping out anything unnecessary to gaining the “easiest” productivity possible.  A true focus on minimalism might even cut revenue in favor of margins by creating less value.  Opposing this approach would be a total focus on viability, in which we invest to upgrade processes and resources regardless of ROI to achieve the most robust value stream possible.  Ideally, this would give us sustainable competitive advantage, assuming we raise so many barriers to entry that we create near-monopoly conditions.  However, most gaining economic rents in this way can take years to capture, making the investment risky.  By maintaining a tension between minimal investment and maximal viability, we can minimize necessary inputs while holding output constant, increasing process ROI.  If desired we can then establish a path for increasing input while holding ROI constant.

With mobile apps, we facilitate minimum viable product by transforming the nature of the steps taken in a workflow, the number of steps, the number of operators required, and minimizing time to complete each step.  By removing all delays in information transfer and introducing autonomation we are able to bring downtime to an absolute minimum.  Maximizing ease of completion and minimizing time to completion is therefore the overarching goal of mobilizing any process.

Once we have a full understanding of the next-level lean processes, we take the mobile apps we have dreamed up and create a prioritized roadmap for investment in our app portfolio.  While the “big dreams” white-boarding session is an important first conversation, defining Minimum Viable Product for both the processes we will disrupt and the process improvement investment we will make is critical to ensuring the app roadmap is continuously focused on the improvement with the highest incremental impact.

How to use the Lean Canvas for App Planning

Lean Canvas

The Lean Canvas via http://www.leanstack.com

The Product Vision Imperative

Imagine a Ferrari with no steering wheel and no tires – no amount of horsepower or torque will win the race if a car has no direction. Increasing resources or efficiency without alignment and traction on a common strategic vision is utterly ineffective.  While agile, scrum, and XP will maximize velocity, it is critical that we ensure the well-formed team has ultra-clear, laser-like focus on the goal.   After all, no increase in velocity or decrease in impediments can supplement a lack of understanding of what to build and why it should be built.  This is why the ability to clearly articulate the product vision of an app is critical to ensuring we don’t just build the right app and build it fast – we build it for the highest possible impact.

There is a natural 3-level taxonomy to an app.  The app Narrative (the entire app) is made up of Epics (major features), Epics are made up of Stories.  Because an app (as we’ve previously defined it) is a relatively small and ultra-intuitive tool with a highly focused outcome, stating the Narrative is the Lean way to succinctly express the workflow being created, who will use it, and why.  It conveniently looks like a massive user story:

  1. The Narrative – A a sales rep, I want to support customers without having to turn my back or leave the room so I can build better rapport as their consultant.
  2. Some Epics – Check inventory, Answer questions, Take payment, Notify inventory team
  3. A User Story – As a sales rep on the sales floor I want to use Apple Pay to accept payment from my customer  (Part of the Epic “Take Payment”)

The simplicity of this description will help align the team on the product vision, but it glosses over the business case that justifies the vision.  This can be done efficiently for multiple apps using the Lean Canvas approach to documenting the business case for an app.


1 – Identify the Problem

Because the scale and scope of any given app MUST be laser-focused we must start with identifying the key problem we want to solve.  Building the right app – A Billion Dollar App – means we don’t build a hammer and start hunting for nails.  We identify the nut, bolt, or screw, take stock of the complex setting in which we find it, and build the right tool for the job at hand.

“Customers care about their problems – not your solution.”

-Dave McClure

This begins with the Problem Statement.  The top three major pains for a single (existing) operations workflow often tie together in one overarching “problem”.  The Billion Dollar App for an enterprise should also have no feasible existing alternatives.  We aren’t reinventing the hammer!  Instead, we want to identify the problems that are unique to the organization, making a custom solution the best approach.  If a SAAS product for a non-core process is available for a client’s pain, we do the right thing and suggest the correct existing solution.


2 – Know the Target User

An appropriately sized and focused app must have a well-defined target user base.  In marketplace consumer apps, this means identifying the target market segments in which an app will compete.  For enterprise apps, this is typically limited to single business function (e.g. sales).  While there may be a subset of users that have customized versions of the same experience, we avoid creating apps that lose focus by combining multiple unrelated workflows.  For example, if managers want a dashboard for their sales rep app, the manager narrative (focused on analytics and the big picture) should be separate from the sales rep narrative (focused on point-of-sale conversion).

This is often accomplished by creating User Personas that describe an imaginary but likely user for the app.  In order to properly determine Minimum Viable Product, it is essential to know the “80/20 rule” for the target user base.  There are three personas that will assist with effective planning discussions:

  • The Early Adopter – Knowing your early adopter is critical.  Whatever initial revenue or increased productivity the app will drive, the early adopter will drive it and provide the initial wave of feedback that can inform a pivot.
  • The Average User80% of people will use 20% of the app.  That first 20% of features will also deliver 80% of the value created.  Prioritize the high-impact feature that the average user will make use of and defer the rest until later. 
  • The Power User – This user is both useful for building out the longest-term set of possible features and for helping define what type of person will likely not get everything they want.

3 – Summarize the Unique Value Proposition

Once we identify the problem at hand and who it impacts, we quantify the value a solution has the potential to generate.  In enterprise process improvement apps we call this “Impact” – the time or cost savings potential or the potential increase in revenue associated with solving the pains we have identified.  A business case is incomplete without this.  It is easy to gloss over this in the excitement of imagining an app solution, which is why the App Roadmap Workshop is specifically designed to maintain this discipline – we need to know the value proposition before determining the solution.

Once we know the value proposition we are in a position to move from problem to high-level concept.  This is often easiest to do by drawing from apps familiar to the audience, identifying both similarities and differences that we would expect to see. 


4 – Provide the Solution

With a high-level concept and a quantified value proposition, we are ready to brainstorm the solution.  The goal at this stage is to determine what an app would do for each of the pain points identified.  At this stage, avoid over-thinking whether the solutions are separate apps or features combined in a single app.  Instead, focus on the Narrative that uniquely solves the Problem for each User with an identified pain.


5 – Determine the Product Channels

Determining the Product Channel for each app means determining which devices and operating systems will be supported and how the app will be distributed to users.  For web apps, we need to define the internet browsers that will be supported based on the target demographic or based on insights from IT.  For enterprise iOS apps distributed through a Mobile Device Management (MDM) platform this will require an Apple Enterprise Developer Account that may take several weeks to secure – do not delay this process.  Android, iOS, and Windows consumer apps each have a unique consumer marketplace with their own policies for content and distribution as well as unique marketing requirements (description fields, screenshots, etc).  Regardless of which channel is right for the solution to the problem, add to your to-do list to look through the policies, terms and conditions, and Human Interface Guidelines for that channel.  If your personal device or browser is not the product channel for your target market, be sure to look up a few “Top Ten Best Apps” and “Top Ten Worst Apps” to get a feel for trends in design and performance.


6 – Revenue Streams

The next step in the Lean Canvas method is determining revenue streams for the product.  In the consumer mobile app marketplace this is often referred to as “monetizing” and may be a combination of selling a paid app, using in-app purchases, making space for iAd, sponsored content, or selling data that is collected.  When planning web or mobile apps for the enterprise, the App Roadmap Workshop looks at how much cost or time savings or additional revenue (of the potential identified at the Unique Value Proposition stage) can likely be captured by the business given the possibility.  This is part of an overall Balanced Scorecard that ranks the apps the business has identified in order of Return On App.


7 – Understanding Cost Structure

As part of the App Roadmap scorecard, we work with clients to identify the impact of the cost structure of the business processes we will impact.  This can be done using relative estimation by rating a handful of subjective influences:  switching costs, disruptiveness to employees, cost of waiting, and timeline to capture the value created.  For example, if our goal is to improve the in-store sales process to increase revenue, we need to understand any costs associated with training employees to use the app, costs to change the layout or technology infrastructure of the stores, and the extent to which the change will be disruptive in a way that has a negative impact on revenue as the employees adapt to the new process requirements.

When planning a consumer app, fixed and variable costs associated with the longer-term product strategy are important to identify – an information website, hosting fees, product support, and ongoing development costs should all be taken into consideration.


8 – Identify Key Metrics

Because we identified the numbers associated with the problem we will solve, understand the unique value proposition, and have planned our monetization or impact, agreeing on key metrics should be relatively straightforward.  If an app is tightly focused, there is typical “one number” that we want to move and a few numbers that we are certain contribute to our goal.  Secondary metrics are important because our primary metric is often a trailing indication of success or failure and is therefore difficult to use for short-term planning.  For instance, if the “one number” is increased quarterly revenue, the impact of new features may not be represented for several months.  Secondary metrics like increased traffic conversion, increased items per sale, and increased revenue per sale may provide insights more quickly.  

While the business case metrics identify the how we measure success or failure of the app itself, the Lean Canvas method can be repeated on a per-feature basis to prioritize Epics on the app roadmap.  Key metrics at this point are typically called “analytics” and focus on the impact of any given feature on the user.  This may include a combination of time-to-completion, time per screen, crash-free users, and user-provided subjective ratings (i.e. 1 to 5 stars).


9 – Competitive Advantage

While identifying revenue streams or process impact and establishing the key success metrics for an app allows us to prioritize and understand feasibility, identifying “unfair” or competitive advantage is essential for determining how to sustain long-term margins.  At this stage, a Five Forces or Resource-Based strategic analysis can help determine how barriers to entry can be raised and also identify what quality about the new product or process improvement will be difficult for competitors to copy.

 

Agile Priorities: Keeping Documentation Lean

Agile Transformation

If you want your agile transformation to fail, allow the development team and all supporting functional teams to focus on the waterfall deliverables and dependencies to which they are accustomed.

In “Fixed Budget, Fixed Scope? Be Agile Anyway.”  I argued that agilists, especially newcomers, must understand that the Agile Manifesto is a statement of priorities – at times, tools and interactions, comprehensive documentation, contract negotiation, and following a plan are all part of the product that is created by the process that keeps your teams in business.

In software development, this is the exception rather than the rule.  

For “core” Scrum, the proverbial “one-team-in-a-garage”, this is pretty simple.  Everyone you need is in one room.  When scaled, a delivery organization is often “compound-complex” – it is “compound” when two or more independent functional knowledge areas must cooperate and “complex” when at least one knowledge area has dependency on another (these aren’t fancy concepts, just basic grammar).  The moment a delivery process moves beyond one-team-in-a-garage Scrum, there is compound-complex value stream:

The web team and mobile team will build a user-facing experience, while the middle tier team provides RESTful services, only after sales executes the contract and the Product Owner builds the backlog; meanwhile, UX, BA’s, and QA’s will provide documentation.

In this value stream, the “Wildly Important Thing” is the software that a user will consume in order to drive revenue.

Because Communities of Practice have their own traditions and methods of proving extrinsic value, shifting their priorities is much more difficult at scale.  Plan to change the physical distribution in order to overcome the functional “clumping” that Waterfall encouraged.  Moreover, agile transformation will require finding and eliminating the agency dilemma of managers who built their kingdoms around waterfall values.

Resolving Wasted Effort

If agile at scale has not improved company-wide quality and velocity, it is likely due to waste in the overarching process – you must remove any activity that does not drive value creation that a user consumes and the business will capture.  This is the central rule of the User Story – if it does not make a difference to the user (and occasionally the owner) it is wasted energy, a distraction.  You find this clearly stated, often, in Jeff Sutherland‘s various descriptions of “Bad Scrum” – without delivering working software that matters to the user an organization will be stuck in a self-reinforcing cycle of inefficiency and ineffectiveness.  No one is making a difference in the world, selfishness increases, velocity never improves, no software is delivered.

For a compound-complex process to stay agile, the Lean principles of Just-in-Time and Just-Enough to must be applied to all forms of documentation – business rules, persona descriptions, wireframes, UI designs, sliced assets,  value mapping, technical constraints, market conditions – all are a means to pleasing the user, not the end goal (software that a user values).  The User Story is the cornerstone of efficient, effective product delivery because it is a “reminder of a conversation” about a result from which a user will derive value.  For some teams, a set of wireframes can all but replace “cards”.  An image of a login screen is sufficient to drive the conversations a team needs to have about client-side validation, security requirements, and authentication method.

The Product is Everyone’s Deliverable

To move to next-level agile, at scale, an organization will need to blur its understanding of “business planning”, “requirements documentation”, and “UX Design”.  While there may be a need for full, distinct teams of experts at each of these disciplines, these approaches to defining what the software will be should converge on a single goal – building great software.  A popular article on Lean for UX, Lean UX: Getting Out Of The Deliverables Business leads with this statement:

Wireframes, site maps, flow diagrams, content inventories, taxonomies, mockups […] crystallized the value that the UX discipline brought to an organization. Over time, though, this deliverables-heavy process has put UX designers in the deliverables business — measured and compensated for the depth and breadth of their deliverables instead of the quality and success of the experiences they design. Designers have become documentation subject matter experts, known for the quality of the documents they create instead of the end-state experiences being designed and developed.

Having started my career as a Business Analyst, this is painfully resonant.  It is unfortunately easy for management move from training “the tools of the trade” – spreadsheets, slide decks, requirements documentation, technical specifications – to judging the tools independent of the software to be delivered.

Here are a few rules to follow to get UX, UI, and BA’s out of the deliverable business and into the well-formed team:

  1. Never say “final sign-off” regarding artifacts – whether working for internal stakeholders or external clients, if software is the deliverable, it is the only item requiring sign-off.  Every other artifact is is a tool for getting working software in the hands of users.  Make sure you are “responding to change” at the request of real users of working software – no amount of planning or documentation will survive contact with the user.
  2. UX/UI Refinement should mirror Backlog Decomposition – Prioritizing working software does not mean there is no product roadmap, it does mean that time and resources should only be invested in the software most likely to be built in the near future.  This starts as a process diagram of all possible Epics that could be built, and how the user gets to each of these features.  The upcoming 2 to 3 features should have relatively actionable wireframes.  The team should feel certain about the UI design of the current and next sprint.
  3. Create paradigms, not screens – the most important expectation to break is the annotated UI composition per screen.  Some screens absolutely benefit, many do not.  A well-formed team should have enough shared understanding of technical constraints, design paradigm, and business context that a conversation is sufficient to drive the whiteboard-to-working software process.  Wherever possible, establish a paradigm for a product is intuitive to build.  If it isn’t intuitive to the developer without extensive documentation, how likely is is it the user will find it intuitive?
  4. Document releases proactively, but in accordance with your level of certainty – If there is a product that will require knowledge hand-off, a support guide, or other formal documentation, maintain the tension between what makes sense to proactively document (so you don’t spend a full week post-release) while wary of what will change (likely anything more than a sprint in the future).

Following these rules, the software development process in an at-scale, compound-complex organization can focus on the user enjoying a working product.  Aligning vision and expectations along the agile priorities will remove fear of failure or criticism, increase team velocity, and result in the best possible products.  Then, your team, business, and enterprise can pursue kaizen – and the real magic can happen.

Fixed Budget, Fixed Scope? Be Agile Anyway.

Innovation is Sexy:

Scrum is typically taught with its most innovation-focused form as the example, born from fast-paced software companies who disrupt markets and kill categories.  This is the sexy version of Scrum: a highly elastic process for delivering complex products with emergent design.  In the real world this is not the only context in which Agile, Scrum, Lean, and XP principles can and are utilized to increase quality and velocity.

If you are a newly-trained Scrum professional, bright-eyed and full of hope, do not get discouraged by convergent, fixed-budget, fixed-scope, fixed-timeline projects – be agile anyway!  This is how to do it.


The Agile Manifesto:

It is important to remember that the Agile Manifesto is a set of priorities, not a set of laws. To any extent we can, we strive to prioritize in the direction of team collaboration, continuous improvement, and emergent value creation.  However, there are some occasions when you will have to put additional energy in the secondary priority.  Strategy is the art of trade-offs, so make sure your organization is aligned and the strategic vision is deliberate:

  1. Individuals and interactions over processes and tools – Never lose sight of prioritizing the people who huddle around your solution, never stop collaborating.  Encourage face time and green time.  However, there are highly regulated industries with static expectations, accounting control benchmarks, FDA guidelines, or stable dividends paid to investors for decades.  A well-documented, repeatable process for how software, hardware, or other product will be delivered over the course of a long-term project will assist tremendously with stakeholder confidence.  Make priorities clear on all sides of the contract, set the expectation that communication and availability are mission-critical, but understand that there will be little risk tolerance for out-of-control processes.  Maintain your agility by keeping your document alive and lean, maintain elasticity, but make sure the tools used and the processes adopted, and the pace of process change, gives your fixed-scope, fixed-budget project a stable context for predicting delivery and ROI.
  2. Working software over comprehensive documentation – Delivering builds early and often is the best way to be truly certain of product status.  In emergent product design with incremental feature addition this feels natural.  There is an MVP planned so an opportunity to pivot is assumed, the feedback loop on the progress of high-quality incremental delivery is the best way for stakeholders and users to see and feel the value that is emerging.  When working with waterfall-minded stakeholders – especially if they are an external client – fixed scope, fixed budget, and fixed release dates cannot always be avoided.  However, convergent delivery does not preclude the XP and Scrum best practices of well-formed agile teams and an openness to documentation-heavy products will drive velocity and success waterfall organizations have never seen.  Instead of negative reactions to the expectation of comprehensive documentation, approach documentation as a secondary product and maintain the same expectations of prioritization, collaboration, and responsiveness.  Moreover, a convergent, finite project likely came to you with extensive documentation.  This documentation will require some additional work, but it should not be ignored.  Even though this is a source of waste that is removed during agile transformation and lean consulting in “sexy” emergent product delivery, handling waterfall requirements as documented stakeholder demands can be incredibly helpful in convergent product delivery.  The Product Owner still must aggregate, consolidate, and complete backlog decomposition with the team.  The XP user story and a prioritized backlog should still set the delivery cadence.  Be open to documentation and transparent to stakeholders about its actual ROI after it is delivered.
  3. Customer collaboration over contract negotiation – Good fences make good neighbors.  Some large companies simply cannot risk an open-ended and loosely-defined relationship, especially with vendors or contractors.  If you’re competitive strategy relies on these types of contracts, inspect and adapt.  Find how negotiation can be expedited, build in the process of collaborative relationship change, and build well-formed teams that are as adept at ramp-up as they are at innovation.  The capacity of a Scrum team to quickly assimilate a knew business and architectural context will drive success in products and relationships of all types.  Answering the internal needs of various business functions or developing solutions in new industries requires a team aptitude for understanding new contexts effectively and efficiently.
  4. Responding to change over following a plan – Change is inevitable in product delivery – the demands of the market, the technological tools available, and the state of the product being developed are a state of continuous evolution.  New requirements previously unnoticed will surface in the course of a project.  Even in a mostly-waterfall project, a great Product Owner will apply XP and Lean principals to minimize waste and maximize up-front value.  Great Scrum teams will perpetually improve, increasing velocity.  We often talk about “waterfall projects” versus “scrum projects” when we really mean emergent versus convergent delivery – fixed budget, scope, and deadlines do not preclude scrum, lean, and XP practices, they constrain them to a known outcome.  The difference between delivery by a helpless group of Project Managers and Business Analysts disengaged from team performance versus delivery by a powerful Product Owner and kaizen-crazed ScrumMaster and team is not dependent on emergent product delivery!  Collaborating around the highest value backlog items up front, swarming impediments, and tracking the variance of forecasted-to-actual product-level burn down will allow fixed dates to be met appropriately.  Responsiveness to change needs to be supported by a strong relationship of trust, which must earned.  If you are in a custom software shop, responding to RFP’s and entering into fixed projects is often the inevitable first step to earning the trust that will lead to a more agile relationship, so make efforts to meet the comfort level of the customer’s stakeholders while including a healthy process for addressing requirements changes.

Conclusion:

The values, practices, and behaviors of agile, scrum, lean, and XP have wider applicability than open-ended emergent product design.  Staying open to the unique lessons that can be learned in seemingly less-than-ideal projects will be a terrific opportunity for the kaizen-driven team to grow.  If a rigid process and convergent projects have caused the shine on your Scrum mindset to dampen, step up or step out: don’t let the context defeat you, stay true to your agile values.  On the other hand, if you find yourself in a long-term no-win situation in which you cannot drive change for your team(s) and users, maybe a sexier career path is out there for you to consider.

Incremental AND Iterative Product Delivery

Highly-effective agile teams deliver user-valuable software incrementally and iteratively. What’s the difference?

Incremental Delivery:

An increment is “something added as part of a series of regular additions.” Scrum relies on incremental by employing the user story (originally promoted by Extreme Programming and written about extensively by agile champion Mike Cohn).  The user story is the fundamental building block of how sprint commitments in Scrum are managed.  Incremental delivery relies on intra-sprint-based “vertical slice” delivery, in which new features are divided up like sashimi – as thin as the skill of the chef can accomplish.  Effective vertical slicing is a best practice in Scrum and XP because incremental delivery minimizes uncertainty in any given sprint and release, throughout the development of a complex product.  Vertical slices follow the INVEST rules for user stories:

  • Independent, end-to-end, “shippable” increments of the emergent whole.  The slice could be delivered fully tested without any other product increment and create value for the user or owner.
  • Negotiable, in planning and expectations with users and stakeholders, allowing delayed incorporation of enhancements or, if a major pivot becomes necessary, easily removed from the product roadmap (without previous over-engineering, over-planning, or over-documentation).
  • Valuable to the user or owner, likely in a way that is sufficiently noticeable that it is monetizeable.
  • Estimable by the delivery team because the User Story does not generalize or hide uncertainty.  An inestimable story is often an Epic.  It is either complex enough to warrant a technical spike or compounds enough feature work that it should be broken into independent, smaller, user stories.
  • Small enough to be estimated by a team, with certainty, and deliverable fully-tested within a single sprint.
  • Testable by virtually any team member because the expected outcome is qualitatively or quantitatively noticeable (as part of its being value) to the target user.

The INVEST method for user stories ensures that planning and development occur just-in-time so that the emergent product can regularly evolve in response to changing stakeholder demands.  More importantly, in the fast-paced markets in which agile/scrum/lean/xp programs compete today, incremental delivery maximizes the freedom to release the Minimum Viable Product and pivot in a new direction based on real-time feedback from users.

Iterative Delivery:

An iteration is “a repetition of successive approximations in which progressive versions evolve to a desired level of accuracy.”  Iterative delivery relies on an openness to prioritizing value that is good-enough rather than perfect.  The perfection of a single feature or a single screen, as defined by one Stakeholder, Architect, UI Designer, or Engineer and taken out of the context of the overall emergent product leads to unnecessary delays, lack of decisiveness, and delayed time-to-market and ROI.  The Scrum team avoids working in a silo through collaboration, entrusting the Scrum Product Owner with accountability for decisions.  In contradistinction, over-analysis and churn prior to meaningful user feedback is utterly inefficient and ineffective.  Thus, while Just-in-Time vertical slices maximize the freedom to bring Lean MVP’s to market and pivot as appropriate, iterative and “just-enough” Lean delivery is equally critical to ensure that increments can evolve based on user feedback instead of non-plans made due to (unnecessary) fear of scrutiny.


Connect With Me:

LinkedIn       Twitter