Category: tech

Blog SEO: 5 Simple Techniques to Start Doing Now

1 Comment

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.

DevOps Athleticism

Leave a comment

Let’s face it – being small makes it look easy to be nimble.  Look at your average kindergartener: they may not always be graceful, but their capacity for unexpected action or a rapid spontaneous change in direction at full speed is frequently mind-blowing (for each of mine, it was usually a sudden jump into the risk of oncoming traffic).

So it’s understandable for the established enterprise to look at the youth (and occasional hyperactivity) of startups – and small companies who never grew up – and feel a little fat, a little old, a little bit brittle.

That metaphor doesn’t need to end there, though, because there are also large companies maintaining a portfolio that balances finding new opportunities on the one hand and exploiting new opportunities on the other.  These are two very different operations, though, and companies find balance difficult.  Just like hyperactivity is internalized in the executive function of adults who had physically hyperactive childhoods, that rebellious startup creativity can survive unscathed within the mature organization. By doing so, you can simultaneously continue category-killing through innovation despite staying the course and reaping decades of fruits on already-mature markets and products.

Likewise, to extend the agility metaphor, life is full of athletes in the top quartile of height and body mass index. They top the BMI charts compared to average scrawny-but-chubby adults despite doing it with rather lean body composition.  They are practically outliers, and definitely don’t fit the “standards” set by statistical BMI.  More importantly these individuals put “nimbleness” to shame; and just look at those kindergarteners revere them. Look at the heroes of the NFL: agility doesn’t begin to describe their mastery of movement.  Look at star hockey players in the NHL: they move with the power of an elephant, the stamina of a gazelle, and the grace of a ballerina.  The stereotypical Hollywood karate master black belt may have a very thick, potbelly body-type, but the master needs very little movement, in just the right places at just the right time, to send an opponent flying.

So it’s simplistic at best to “think like the startups” or “be more agile”.  You cannot transplant a culture.  Size alone is not their advantage, strength alone is not their advantage, tenacity alone – as much we love a good underdog story – is not their advantage.  To emulate any ONE  attribute of the lean-agile startup on the rise is foolish.

Stop talking about enterprise at-scale agility like you’re trying to be that kindergartener veering into the street unexpectedly. 

It’s more than being lean, or gaining experience or agility. At scale you need to build repertoire of enterprise-grade DevOps Athleticism!  It’s one thing to have an impressive vertical jump but quite another to jump over a fence, hurdle over a tackling safety, or parkour up a building,

Training for Obstacles

For the support engineer team, kanban looks a lot like an Olympic marathon team.  You constrain WIP (focus/movement pattern), create a sustainable pace, and fuel as you go – you train for the long haul by (basically always) running for distance.  It may be fragile spaghetti code built over the decades, but you your crack team knows it inside out.  But that’s not the majority of your at-scale enterprise.  As you get further from a continuous flow of relatively similar requests and move toward innovation and greenfield disruption efforts, kanban and even scrum are going to fail unless you include the assumption of uncertainty and churn in your overarching process.

This is like the difference between a New York marathon versus Tough Mudder or another obstacle-rich competition.  If you don’t build your capacity for speed-strength and coordination against unexpected obstacles, you’re likely fall short. The long and short of it is, if you can count on a marathon, kanban your way to glory.  If unpredictable obstacles and risk-taking for glory are fundamental, stop whining and start training. Look for extra opportunities to beat down tough challenges instead insisting on a slow and steady pace.  Speed and sustainability need to be loosely coupled in a strong DevOps process.

Jumping the Fence

I can tell you from experience that maximizing raw strength in the barbell squat does not correlate to jumping higher.  If you need to jump higher to make a layup, you do things like box jumps.  If your really daring, leverage your box jump into jumping over a 3-4′ fence (or hurdle) from a standing position.  Raw strength on the one hand and sprint speed on the other don’t give you the actual agility, coordination, and explosive power you’d need.

Similarly, coordination of multiple teams is more complex than strengthening, quickening, or improving communication with each team individually.  Establishing a cadence of synchronization and opportunities for cross-pollination of ideas – even as you increase the independence of each team  

This extended metaphor has a great caveat – go find a 3’ tall picket fence, stand in front of it, and try to jump over.  Assuming you haven’t been practicing, I bet your body stops you.  The same is true of a healthy DevOps system – when you try to launch into a painful bout of stupidity, the developers stop you.  If you’re smart, you don’t force yourself into a giant failure.  Instead, you practice a bit and ramp up your agility to get your entire body confident you won’t end up in the hospital.

Throwing a Punch

You don’t throw a punch with your arm.  You throw it from the ground up, leveraging the perfect twisting launch of one square inch of fist powered by your entire body.  If you’re the square inch that gets to land the winning knock-out blow, don’t get cocky.  You’d be nothing without the support and power of the entire body.

5 Simple Rules for Real Agility 

4 Comments

There is a very wide spectrum from the mythical evil-waterfall-monolith to a perfectly lean and utterly agile continuous delivery of value. In fact, scratch that, it’s not really a spectrum. It’s not even a consultant’s two-by-two matrix. It’s a complex multivariate systems-view that is needed, and fighting religiously for absolutes doesn’t help improve any of the real trials and tribulations on the front lines.
Come on – Don’t try to enforce one-size-fits-all agile or lean or kanban. Instead, create your own adaptive center of excellence from any approaches & tactics, new or old that can provide insights into the variety of techniques that can be adopted for each situation.  

For example, a really well-formed support team could move to kanban and get rid of most of the scrum ceremonies. Likewise, not every multi-scrum-team product needs a cadence of Program Increment planning – but (be honest) some do.

The bigger the organization, the more important it is to be practical in your approach to change you’re passionate about. Self-check: Are you asking for a change that makes the organization easier to work in, better at serving the customer, or more sustainable as it grows? Great! Don’t let fundamentalism get in the way of the spirit of agility and the purpose of your organization.

….Especially if you are an enterprise that is “mid-transformation”.

In fact, rather than worrying about drastically changing to a new and elaborate process with all the answers (which will definitely FAIL), there are just a few underlying principles that will help evolve an enterprise toward lean agility:

1 – Each time you make a business decision, make one that makes it faster to validate your assumption than if you hadn’t made a decision at all.

Anytime you make a decision, make it easier to recover from it as an organization if you are wrong than if you had done nothing at all.

2 – Challenge the biggest assumption first, working to disprove one hypothesis at a time

3 – Each time you touch code, leave it simpler to understand and easier to change than if you hadn’t coded at all

4 – Create an environment of psychological safety for your people

5 – Do no harm to the user

The DevOps Secret that IT Won’t Tell You

4 Comments

DevOps. SAFe. Scrum. Kanban. Did you shiver? The experts have you scared you’re doing it wrong (you know, IT – all of IT). The certificate-teachers need you to need them so they can get paid. The coaches and consultants are taxing your #FOMO (Fear Of Missing Out) on ALL THE AGILE.

Get. Real.

It’s an impossible dream: The perfectly lean and agile software process would be just one person – a masterful engineer with great people skills and business acumen who can hang around a group of people to see what troubles them, create an intuitive software tool that relieves the pain, and collect cash from them while obtaining ultra-constructive feedback. In other words “dev” and “ops” as one person.

Ever seen that happen?

That said, every additional person involved in the flow of DevOps information is either a value-addition or a source of systemic waste. More often, everyone involved is a bit of both. As more bodies are thrown at a problem, it is likely any one of them can only spend 10-20% of their time actually adding value. The other 80% – and all overtime – is typically waste due to waiting on information from others, or over-documenting our value-add so others can consume it.

So it isn’t that IT won’t tell you the secret, if they know at all. It’s easy to crack jokes about how little other people accomplish despite working long hours, but less likely that anyone raises their hand and volunteers the truth about how much time is wasted.

– Waiting for clarification

– Waiting for updates to install

– Waiting for SVN code check-in

– Waiting for someone else to check their code, setup a VM, or answer what their code means

– Waiting for the next meeting

– Waiting for the inspiration to work on something meaningless to you

The great big DevOps secret is that no methodology will fix all that waiting. Over-specialization creates a world in which teams throw big piles of shit over the fence, each group speaking it’s own language that no other group understands. New philosophies won’t fix bad relationships, a toxic culture, and shit tools. It takes time, work, and fearless leadership.

Otherwise, Agile, Scrum, Kanban, and DevOps – or any other recipe for “when to meet” and “what to document” – are like 30-day fad diets; it’s a false hope and a gimmick and it doesn’t change the sedentary fast-food lifestyle that keeps you fat in the first place.

10 Best Product Innovation Techniques

Leave a comment

Need to get a new app, web, or software product to market?  New to the game?  Here’s a handy Top 10 List of practices I’ve discovered along the way.  Instead of exhaustive explanations, Google any words below that are in bold and you will find a wealth of information.

  1. Live a little: Find a significant problem real people have.  Since this really isn’t a technique, go watch Seth Godin’s TED Talk – The Tribes We Lead
  2. Define a User Persona: Define who has the real problem with enough precision a stranger will understand you -For instance: “Women in their forties who get party planning ideas for their children’s birthday using Pinterest” and NOT just “Moms.”
  3. Is the group big enough to support a business model? Time to make a Lean Canvas and share it with a mentor or colleague you trust will give constructive feedback. Also check out How to use the Lean Canvas for App Planning
  4. Customer Interviews: Listen more.  Go to the place.  How are pains currently dealt with?  What is the inefficient current workaround or ineffective existing alternatives?
  5. Empathy Map: Pick an early adopter. Take their picture if they’ll let you.  That’s your new Hero Image.  Capture what she thinks, feels, sees, etc in the moment when the pain occurs.
  6. Pain-Driven Design Roadmap: The problem you want to solve relates to an overarching process or workflow that your target person already does. You should have witnessed this in all the steps above.  Create a prioritized roadmap of solutions based on the problems.  I use a variation of Lean Process Improvement described   Don’t get too attached to this lightweight plan, your goal is to disprove it.  Whatever you can’t disprove through experimentation gets to stay!
  7. User Story Mapping: Take the first item in your roadmap and break it into features. Put those Epics in the order a typical user will access them.  The break them into the tiniest imaginable User Stories you can.  Draw a line that gets rid of anything that isn’t absolutely necessary.  This is a great and tactical write-up via Atlassian’s blog: Guide to Agile User Story Maps
  8. Establish the One Metric That Matters: This will change over the life of the product. For a brand-new app, this might focus on “engagement” – For example, “How many users make it all the way to sending their first Tweet in Twitter?”  Make sure your MVP makes tracking that metric, as well as A/B testing and cohort analysis, possible.
  9. Scope out your Minimum Viable Product – keep cutting. You need so much less than you think.
  10. Experiment: Establish a baseline, be honest about your assumptions, and test the validity of each hypothesis.  If you don’t know much about delivering innovative products, check out Agile or DevOps and the Lean Startup for thought leaders and great ideas on getting better at innovation.

 

 

Defect Prioritization

1 Comment

Defect Prioritization: Everything you ever wanted to know but were too afraid to admit that you needed to ask.

One of the biggest agile religious debates that seems to get people up in arms is backlog prioritization when planning has to balance known defects (especially in production) against new feature work.  Let’s dig in and find a sensible approach here.

First of all, realize that it isn’t a fun situation for developers: fixing a defect older than two weeks, even if you wrote the code yourself, is like looking at someone else’s work.  Especially if it is the cause of a problem, it hurts inside to look at it.  You wish you could re-write the whole thing because you’ve grown and learned and you’re a better developer than you were then!  I get it.  Naturally, it sucks that you can’t do that because you’d end up down a refactoring rabbit hole due to all the other code that depends on your code.  So you end up feeling like you’re adding duct tape to a hole in the hoover dam.  If you’re fixing a bug in code you’ve never seen before, its like your Product Owner told you to fix a hole in the Hoover dam, but said it in a language you don’t speak, while handing you a box of duct tape and shoving you in the opposite direction of where you need to go.  Support engineers – if they actually like what they do – are a very special breed and should be your best friend.  Get them a Snickers bar and a thank you card sometime.

Second, the “triage” work for identifying the importance of bugs (if that happens at all) in which a manual QA tester writes up a ticket and picks a “Criticality” level is a joke.  Even if you had an elaborate definition for each one, who cares?  A crash that impacts 70% of users is “critical” why?  The defect is critical to… what?  To who?  How many people?  How much money?

Now, the lazy moral high ground of newly trained agilists is to insist you should’ve never let the bugs out at all.  Six Sigma Quality baby!!!  That’s a nice thought, and a very valuable standard if you are starting a completely new project on the latest and greatest stacks.  You know, an iOS 9+ iPhone 6s or later mobile application from scratch.  Then, I do advise you to build less than you think you should, think harder about whether or not each feature is actually important, and ensure that no defect gets into the App Store. 

That isn’t most software and that isn’t the problem established software companies are grappling with while in the middle of an agile-at-scale transformation.  If are a Product Owner for 10% of an application older than three years, you definitely have defects and you definitely need a rule of thumb for what to do about them.  It isn’t your fault, but it is your responsibility.  Operating systems evolved underneath you.  Hardware was replaced.  Vendors changed.  SDKs stopped getting updated.  People changed.  Deprecations occurred.  Now you have a list 1,000 decisions to make.  In that scenario, the moral high ground “you shouldn’t have made any defects!” is lazy and unhelpful.  That’s not the reality and it provides no answer for what to do once you already have defects in production.  There’s really four approaches to consider.

1 – All About the Money:

On the one hand, calculating the ROI of every User Story then attempting to apply the same methods to your production or other leftover defects will require a pretty rigorous approach to finance, accounting, and statistics.  A simple example – if a LinkedIn share crashes every 100th time I cross-post to Twitter, what is the ROI of fixing it?  I’m not a paying customer nor is Twitter.  Should I just leave the crash and hope people don’t complain too much?  No, I don’t think anyone would suggest that.  That said, there definitely is a statistical algorithm for whether or not that crash is likely to impact my decision to become a Premium Member in the future.  But if the crash takes 11hrs to fix, test, and deploy while the data mining, analysis, etc takes 60hrs to gain a certainty of 75% – why on earth would anyone not fix the defect and move on?  Eric Reis popularized the saying “Metrics are people too” while Ash Maurya adapts this to say “Metrics are people first.”  That is to say, if you have crash count of 13, not a very actionable metric.  If you have a percentage of engaged users experiencing a crash in version 1.9.3 – you have an actionable metric, but that metric represents real people who are annoyed in real life about that crash!  Quantitative data needs to drive qualitative insight, not ever-more-complicated quantitative analysis.

On the other hand, there are important occasions when the money makes a difference.  If you have customers with a Service License Agreement or paid SAAS users threatening to leave or your actionable product metrics are moving in a scary direction on account of a defect or the perception of poor performance, the money should be the incentive you need to prioritize fixes over any new feature.  Once a customer is gone they are incredibly unlikely to come back.

2 – Actionable Product Metric: Oops

Oops!  We stopped talking about money and started talking about product metrics!  There is a good reason for that – if you prioritize the development effort that improves Acquisition, Activation, Retention, Referral & Revenue (AARRR!) then you are by default increasing the money.  ROI is not even the money question to solve, is it?  If you have a fixed team contributing to the revenue of a product, ROI variability or Gross Margin variability is what you actually want to track – as long as the costs per month to maintain and improve my product is outpaced by the growth of revenue from paying customers, the ROI is there and the Margins are there and everyone is happy!  The problem is that revenue, ROI, and Gross Margin are extremely lagging indicators of success.  They are a good indication of the stability of the performance of a company over time, which gives investors the confidence they need to keep the money there, but multi-year lagging indicators are very poor metrics for the decision-making of the teams that managing, maintaining, and improving the product.  Growth of total users or active users can be a great indication of possible network effects long-term.  Both of these long-term performance indicators are symptoms of competitive advantage.  NOT the cause.

Now we have the cart before the horse though.  If you have legacy production defects in your backlog and want to move to cohort-based split-testing, your defects are the NOISE in your SOUND.  In the example crash above, if you knew cross-posting to Twitter was an important proxy metric for Referral, the possibility of a crash is also the possibility that I don’t try to engage a second time.  If that defect existed before you began using cohort analysis and split-testing, your viral coefficient is already distorted.  So if your agile release train is making an exciting and important stop at the actionable metrics station, make sure to prioritize any defects that could distort the reliability of your pirate metrics and future experimentation.

3 – Fuzzy-Weighted Economic Value Algorithm: 

A core concept for how the backlog should be prioritize in a lean-agile environment is maximizing the flow of value-add and minimizing waste.  If you are continuously deploying, the scope of feature releases can take a back seat to actually committing to the long-term awesomeness of the product.  Of course, as Ash Maurya says, the product isn’t the product, the product is the sustainable business model – and that’s not a fixed-duration project, that’s a commitment to continuous improvement of your unique value proposition.  So in good lean-agile, at any given Program Increment planning session, you do not need to be certain that your ROI calculations are perfect or your developers will be fully allocated or your that your schedule is on track.  You have a fixed release cadence, only scope may vary.  You have a large backlog, selecting the best possible thing to build matters.  As we said above, if your revenue growth outpaces your cost growth, the ROI takes care of itself.

The Weighted Shortest Job First approach is very useful for exactly this.  Because everything else is a lagging indication of good decisions, the Relative Cost of Delay and the Relative Job Size are the most important factors in job sequencing.  Let me reiterate.  Sequence = prioritization.  Under the assumption that small legacy defects require small individual effort while large value-add features take multiple sprints to roll out, you’ll likely always fix your bugs FIRST.  Which is good.  No one likes a crappy product, no matter how much “SOCIAL!!” you add to it.  Burn your customers long enough and they will abandon you.  Every software product is replaceable if you make the pain of use greater than the pain of switching to an alternative.

Over time, three things will happen.  You’ll get to a point where the outstanding defects will require large-scale refactoring effort while your stakeholder (hopefully) get wise to the fact that a smaller improvement with more certain economic value add is more likely to get prioritized.  At that point, you have flow and hopefully rational planning and discussion will rule the day on deciding what to do next.  On that note….

4 – Politically-Intelligent Fuzzy-Weighted Economic Value Algorithm: 

If you aren’t entirely lean-agile, aka you are still mid-transformation, aka “the top” still works using their old plan-driven paradigm while somewhere down the line an agile-savvy person tries to smooth the flow of that work, you need to add something for portfolio-level politics that impact your program-level prioritization.  In this case, while you may not share it too publicly, adding more scores for which stakeholder you are pleasing should be considered.  You can then weight each of the relative scores, like proxy-voting for your stakeholders.

Yes, that means the old-school problems will be continued because you are giving the important people at the top some blank-check preferred stock when it comes to your backlog prioritization.   The unfortunate alternative is that you live in silly denial that their perception matters or that backlog prioritization is not a political question as much as an economic value you question and the people “at the top” or “in the business” continue to hate agile and second-guess every decision you make.  Concessions to a powerful VP today help earn you the trust you need in order to move prioritization to a more rational approach later.  Admit where you are, challenge it bit-by-bit, and work to improve it.

What does that look like in practice?  Hopefully there is an IT leader at the top too in your large-scale silo-heavy organization.  Hopefully that IT person or a Quality person up “at the top” can be one of the political variables in your weighting approach.  Don’t pit the CEO against the CTO as a Product Owner, that just makes you look like a chump who can’t make difficult decisions yourself.  Gain buy-in and provide enough visibility before planning sessions that no one gets blindsided by your decision to prioritize refactoring over that VP’s screams for “SOCIAL!” 

To reiterate – THE BACKLOG IS A POLITICAL ARTIFACT. 

Your solution is only partially economic or financial or social.  This is not a democracy.  Don’t go asking for votes.  It really isn’t a democratic republic, either.  And it is definitely isn’t just user story meritocracy.  Slapping a relative business value tag and sorting is begging for failure and distrust at your methods.  It looks lazy and it is.  You have to influence the right people to make the right decisions and that takes work.  If you’re lucky, its close to a full-time job and you have job security now.  Congratulations.  But seriously go fix those bugs.  They’re lame.

The Leader I Am

Leave a comment

The foundation of the leader I am today isn’t listed on my resume. Those formative moments don’t really belong in the official documentation of pursuing autonomy, mastery, and purpose through software product innovation.

My training in leadership did not begin during my MBA or any of my agile certifications. It began by watching my father’s servant-leadership as a minister and the mentorship of my high school English literature and composition teacher.

There was a day that came when Mrs. Bernsen, my high school English Lit teacher, gave the disengaged classroom an admonition to inspire our focus as we read and discussed selections from Ralph Waldo Emerson’s “Self Reliance”. Who we choose to be today sets us on a path for who we will become in 5 years. I took that idea very seriously. I studied “Self Reliance” several times and began teaching its ideas to anyone who would listen. I had decided I was a philosopher who loved teaching people to strive for introspection and self-ownership of their journey in life. My career has been expanding on that theme ever since.

As 1st chair trumpet in band, I learned the power of servant leadership and inspiring people to the prestige they wanted. I played third part because I was naturally the loudest and it made the whole band richer. I made sure everyone who wanted one got a chance at a solo that they would succeed at. Senior year we had a particularly challenging piece and not enough trumpet players to effectively make it beautiful, so I noted out with my second chair how he and I would trade off between 1st and 3rd part, ensuring the high notes were never missed while the low notes were the right strength.

As a Youth Minister in college I found the power of Accountability Partnership in learning plans. There is truly to many virtues and too much knowledge in life to tackle at once. Whether a mentor, teacher, or friend, finding someone to share your personal development goals with, and being someone who can ask about progress, is essential. Saying it out loud makes goals more realistic and personally expressing them to someone simplifies the ability to prioritize your priorities.

As an assistant manager in retail and in a restaurant after completing my philosophy degree, I learned the importance of being the janitor. Clean up the messes, socially and physically, that your team can’t get to so that their flow isn’t interrupted and the customer is happy. You show up at 2am to unload the new stock so someone else won’t have to and you run the reports and call the customers no one else wants to call.

Yesterday I was asked to share a story that exemplifies my leadership style. I shared a simple story – I recently noticed a group looking a little lost because there were no meeting rooms were available and they had a conference call. I gave them my office. Their work and that customer were important than my comfort. I worked in the lobby.

All of these moments stay vibrant in my mind, as the milestones of how I became a leader today. Most important though is the example of my dad, which laid the foundation for how I view people in need of guidance, listening more than teaching, and serving where no one else wants to go.

So when you ask me about the leader I am today in the software space, it centers around four goals, built off the foundation described above, and countless other tiny moments along the way.

I use workshops and one on ones to build the confidence and vision of my team so they can pursue their own sense of meaning and purpose at work – I can only help build the bridge between company goals and values to personal sense of prestige and love of your work.

I use learning plans and information sessions to help my team members pursue their sense of mastery in their craft. I am constantly learning what they want to learn so they have someone to meaningfully converse with, while playing the role of accountability partner much more then mentor. I don’t lecture or train so much as play the role of knowledge janitor, cleaning up the chaos of possible theories, tactics, and practices, finding answers for people and resources and thinking a few extra steps ahead about how we can grow.

I am an advocate on their behalf when political games are in the way of their autonomy, while challenging them to become more cross-functional, more collaborative, and better at self-advocacy. I want my people to be leaders who are better at defining their own processes and taking pride in their work because they trust I can challenge them. The most important trait of a leader is gaining trust by proving that I have their back.

How the Sausage is Made

3 Comments

Conventional wisdom: “No one cares how the sausage is made.”  I’m sure you’ve heard this before as well. Maybe it gets followed up with more assumptions: “The consumer cares about the product.  They want the solution.” However, that’s not really true either. They care about their pain. The solution is irrelevant unless the pain is relieved. If you’re really great, you replace pain with pleasure, and build a lasting relationship that your customers are excited to tell others about.

The Sausage

So let’s talk about this proverbial sausage.  When you are hungry at a game and a sausage wrap stand is the only food or you’ll miss the entire game?  No. You probably don’t care about how the sausage gets made. You care about your hunger. You care about the solution. You care about the price. 

Luckily, we don’t live in the local monopoly conditions or restricted logistics of that example.  There are true artists of the craft, solving new pains everyday.

Have you seen how a master chef makes tantalizingly delicious and unique sausage from scratch?  If you love sausage, you do care how it’s made.  You would buy recipe books, watch reality shows, do factory tours, and attend sausage festivals. There is a huge difference between being an artist with a following versus a monolith with a secret. Which company are you building?  Naturally, I didn’t write this post to discuss sausage (though after talking about it so much I’d really love to fry up a batch now).  This is really about sharing your product backstory and software delivery methods. 

Think about a great chef. The kind that writes recipe books, heads up gourmet restaurant chains, blogs about food, hosts a show, and even gets invited as a guest to cook on other people’s shows.

Imagine Martha Stuart or Emeril Legasse teaching their audience about homemade sausage from scratch.  They smile and cook with their pre-measured bowls of colorful ingredients, hand-grinding the sausage.  The sight and sound of the fire, and sizzle of butter in the pan make you certain you’d want to eat not just any sausage – that sausage.  The great chefs care how the sausage was made whether you care or not. They make the best sausage they can and teach others to try their methods even if most people will never bother to make it the same way. 

So, even though what we are really discussing here is either 1) ”no one cares why your product was made” or 2) ”no one care how your software is developed” – I think that’s drastically incorrect. More importantly, when someone says “no one cares how the sausage is made” to me, I know it’s a symptom of something terrible in the prestige economy of the superorganism that could someday bring it to its knees, never to rise again. 

Now we can qualify that old saying…

“No one cares how a faceless factory makes boring sausage.”

Don’t let your factory remain faceless. No matter how boring the boots-the-ground element of your product delivery may seem, those are people who are representing you.  You can either take the Ice Road Truckers and brewery tour approach to your product delivery or you can hide it away. Even the most faceless factories have tour guides. They have a script, sure. This is a marketing opportunity for your customers who are most likely to give a referral. If they show up to see how the sausage is made, give them a taste of the experiments that you aren’t mass-publicizing yet. This let’s you find your early adopters.  That’s a special relationship that you should encourage, invest in, and keep personally engaged.

Go take a tour of a big beer factory and a small craft brewery, compare the two and imagine what a “brewery tour” of your software company would look like.  The big beer companies have a loyal fan base and brewery tours. The ingredients are well-known.  You can even try it at home.  Operational effectiveness, consistency and quality, and reliability are the big beer maker’s keys to success – not proprietary ingredients.

Don’t be afraid to demo upcoming features before they are finished.  Your opportunity to learn and from customer interviews during an alpha release cannot be understated – give them a tour before you make them work for you.  Don’t just make a website, make a fan page too.  Show people you care about what you build as much as they do. Make the digital delivery part of the human dialogue.  As it turns out, you can’t make people get interested in you by yelling “I’m interesting!”  Telling people your product is the best (today) doesn’t say much at all.  Showing them that real people are making sure the product will continue to get better, teaching them what you wish you knew 2 or 5 years ago about the pain you solved and how they can solve it too – then they might be interested. 

“No one cares what the ingredients in the sausage are if they can’t see and hear the artist who uses them, the special process for preparing and cooking it, and insights in why decisions were made.”

The individual lines of code you write aren’t proprietary. Maybe one or two shouldn’t be public knowledge for security reasons.  The rest are meaningless without the rest of the code base and all the people that create viable product-market fit.  Your accounting KPIs, eCommerce analytics, or SDLC aren’t that special on their own either. Your templates are common knowledge to anyone with experience. 

Your people – coming together to do something bigger than themselves -THAT’S special, and while you can lose that no one can steal that. I suspect there are some companies that would never approve a marketer posting a photo of coding-in-progress on Instagram for fear contents of the screen is proprietary. Yet, any developer would tell you that turning frameworks into a worthwhile platform people can reuse is incredibly challenging. No, nobody cares what your product planning meetings or your Scrum process is, unless the people who make it special are front-and-center.  You can make an official statement – like so many companies – that your people are your greatest asset; but when you hide your people and how they work from the public eye, the message is clear, not only to your people but to your customers as well: you don’t take any pride in the sausage-makers, so the sausage probably isn’t that special. 

This is the difference between posting on Twitter “My apple pie is made with 20 apples” versus a video explaining which apples to use and why, the process you use when you pick them out at the store, why you bought them where you did, etc. Teaching the generations coming up behind you makes you matter, not protecting a secret that isn’t even a secret worth stealing. 

“People don’t care how the sausage is made unless they trust you share their love of great sausage.”

The difference between having consumers and having an audience is sharing their pains, pleasures, fears, and passions. Don’t sell to people, mentor them. Don’t market to people, teach them. Is it possible that some people want to know how you make gumbo but not how the andouille sausage was made?  Absolutely.  That’s the line between retention and referral – if you say secret to great gumbo is making the sausage yourself, the real advocates who trust you as an artist and an expert will pay to learn your sausage-making methods.  The opposite is true too.  If you don’t share the passion or demonstrate your expertise, no one is going to listen.  They can spot you as a fake from a mile away.  They know sausage isn’t a priority for you and nothing you say about making sausage is worth sharing with their friends. 

“No one cares how you make the sausage if YOU don’t care how you make the sausage.”

This is probably the most on-point.  Teams who think no one cares how the software is made also don’t have much pride or faith that their process is worthwhile. Sometime the biggest challenge is just showing the engineers how great they are. As the leader, you have to be like a head chef: It’s not just that you love and take pride in the craft, it’s your time-in-the-fire and belief in the process itself that give people the confidence to follow you.  Sure, your customers may not want to sit and watch code being developed for hours on end, but throwing a montage, hosting meetups, YouTubing behind-the-scenes footage, and some exciting reality show commentary is something people love and look for as part of the complete package. That type of messaging let’s people know you care about the work it takes to solve their pain. By giving some visibility into how much diligence, care, and work is put into the next release, your customers can feel they were part of the experience and have a better appreciation why updates and new features can take awhile to release.

If you want the inspiration I had when I wrote this, go read these books:

Rework

Steal Like an Artist: 10 Things Nobody Told You About Being Creative

Show Your Work!: 10 Ways to Share Your Creativity and Get Discovered

Photo via The Digital Marketing Collaboration

Identify Existing Alternatives

Leave a comment

Identify Existing Alternatives

When you’ve identified a pain that is shared by a sufficient group, don’t start solutioning yet!  There is actually another crucial step.  Identify the existing alternatives.  If a pain is already perfectly met, it may not make sense to add that new feature, create that new product, or start a new company.

Understanding Workarounds

With Emphatic, some existing alternatives were Tweeting just a photo of the book with a caption, typing notes or quotes manually while fumbling with the book, and (for the research paper student) Microsoft Word does have a tool to help with your citations.

Each of these cases are examples of a workaround, since none of them really solve the key pains – frustration and wasted time typing notes, citation grey areas, relying on my brain’s “file system” for tracking and relating insights over time.

If you have ever emailed a document to yourself, that was a workaround.  AirDrop is an amazing solution to the specific pain “I want these three photos shared from my iPhone to another device Apple device.”

To find workarounds, you need to take a gemba walk.  Go to the place where the pain occurs.  Observe, ask questions, listen.  The closer you are to the pain you need to solve, especially if it is as critical to you as it is to your customers.  This isn’t all user experience fluff.  The workarounds and nearly-good-enough products you see today are the “Threat of Substitution” part of Porter’s 5 Forces after the new feature/product/business exists.  If you make scissors and someone cannot find them or afford them, tearing the paper is a viable substitute.

Competitor Research

The usability and customer interview part of competitive research is both easier and harder than ever due to the internet.  Where there is pain that is significant and shared by a group of people, there is guaranteed to be a place on the internet where you can observe what has been said, what people advise each other to do, etc.  Don’t fall into the temptation of trusting this as the only insight you need.  You need to get involved in the discussion, ask open questions, and listen (even on an internet forum).

As it turns out, Emphatic does have a competitor.  Although I had searched for a direct solution to my pains and found nothing, this week while searching for a workaround I found Quotle.  This is very exciting.  You see, Quotle is exactly what I had initially thought I’d build to solve my pain before I read Rework and Running Lean. It is an OCR scanner for paper books that looks like Instagram. 

I had envisioned artistry and community and got a technical proof of concept. 

Unfortunately, that’s the disconnect that accumulates into a product/market misfit as a demand to alleviate a pain moves from the user through the stakeholders and Product Owners to the development team and back to the user.  More on that later:  in the mean time, download Quotle, try it out, and send me what works and what doesn’t work about it.  I’ll be asking the same of people at the library.