Category: Marketing Strategy

Life Hacks, Product Thoughts, Startup

Thoughts on the Bus Problem

Posted on by gregmeyer

osman-rana-222325

(photo by https://unsplash.com/photos/HOtPD7Z_74s)

What’s the most important thing you do at work?

Most of us, when asked “how do you create job security”, default to explaining a way of interacting with others that only we can do. If you have unique skills, of course you would want to create a solution where you can solve the problem. It’s romantic to think that you – the cowboy or cowgirl – can race into the important situation and solve the problem where no one else can, or do it faster than anyone else.

Described differently, “I am the only one who can get it done on time and under budget” also looks a lot like “I am a bottleneck”, or “my company is now vulnerable to the ‘Bus Problem’, where if I get hit by a bus my company will have absolutely no way to do the things I know how to do. These statements now look a bit different.

A Corollary To What You Do Today

But what if creating personal job security looked completely different and had more to do with creating systems everywhere you go that help everyone else in the company raise their game? In this version of the bus problem, maybe the solution is to make bus schedules (so that all buses run on time), and develop contingency plans (like snow routes) for what happens when there is inclement weather or other unexpected behavior like traffic?

The best way to solve the problem of institutional knowledge sharing is to share that knowledge. Duh. But it means more than simply barfing out that information in whatever messaging suite happens to be the flavor of the month. True knowledge sharing means that you can isolate the facts and share the strategy implications of changing course, that you can write a procedure anyone in your company can follow, and that if you are not in the office the process works without you there.

What does this look like in practice?

Let’s say for the moment that you are responsible for updating the team on a new feature in your product. As a consumer of that information inside of the company, each person in each role needs something different. Sales might need to know if the price of that product changes or if specific customers had been waiting for it. Marketing might need to know if there are marketable features that could be shared with a wide audience. Engineers might want to know if there are new things to test and build. And Customer Support needs to know the typical things customers will ask and how to solve their problems.

Compare your original goal of becoming the only one who can solve a critical problem with the goal of sharing information with everyone in the company at the right time to ensure a productive product release. If you don’t create systems that ensure people on your team know what they need to know before you can tell it to them, you will fail. Your participation in the process should be the reinforcement of the knowledge, rather than the only way they know that information.

Start today by writing down an important thing that no one knows into instructions that person can follow, and then take the day off. Train a trusted resource, take the day off, and see how things went. If you get to “One in a Row” on this problem, you’re ready to tackle the next critical business process you own until the whole business can run without you telling them which buses run next on the schedule.

Advertisements
0
Product Strategy, Product Thoughts, Uncategorized

One of the most difficult product decisions is “not yet”

Posted on by gregmeyer


(Photo courtesy of https://unsplash.com/photos/3IVOgGIBsM0)
I recently had a (great) idea for a product. In my head it made perfect sense – a way to make it easier for people building presentations to get instant help from a trusted freelancer. Surely many people would be excited to try it out. 

The idea went from sketched-out prototype to tech exploration to see if it was possible to execute the thing I was thinking about, and two things happened. First, two very smart people asked whether this is a problem that anyone has,  and whether I had any data to prove the size of the market. Second, I realized I hadn’t done enough work to move from idea to execution.

“Of course,” I said, sharing market validation stats and thinking about channel partners. But then it hit me – I hadn’t yet taken the fundamental step to validating the market need by hand with no tech investment and no real effort spent. Ideas are a dime a dozen until they have some traction.

And it made me consider the optimal way of moving from idea to idea++, or taking the first next step toward validation. “Paper prototyping,” – the effort to simulate the experience of building product without actually building that product – is useful when combined with tests to establish demand. 

In this case, what was needed was a plan to ask people (ideally those I don’t know) to state that 1) they needed help with presentations and 2) that they are willing to pay other people to solve that problem.

One way to test that would be to use an existing site where people request freelance assistance (let’s say Fivvr, Upwork, or similar) and put up an ad for services. The responses to this ad would give one set of signals for demand. Then, the type of work that resulted might help me determine whether the initial hypothesis is worth more thinking. And third, the initial revenue would give clues to the potential profitability of the idea.

Do I know whether I have a great product idea? Not yet. The next step is to validate whether presentations made “good enough” are sufficient for most people, most of the time. If that’s the case, on to the next idea, until there’s a bit more signal that this one is more than a momentary aha!

0
Marketing Strategy, Product Thoughts, Uncategorized

New things are easier to sell when they seem familiar

Posted on by gregmeyer

marc-fulgar-165425
Marc Fulgar

Imagine you are selling a new drink (perhaps in a new category) and you’re competing against Coca-cola. You’ve invented a nootropic brain drink that helps you stay calm and alert while coding, and it has a pleasant natural fizz to it. It might even be an unusual color like purple. Taste tests from prospective customers have been successful and the effects bear out from your claim – coders love it! Continue reading →

0
Product Thoughts

A Reminder Hack For Daily Metrics

Posted on by gregmeyer

What if you had a conversation with your metrics about how to improve your business? Or more accurately, what if your voice-enabled agent asked you every day how you were doing?

A simple idea with with big implications

You might start with a simple question, like:

Hey Siri, how many widgets did we sell yesterday?

Ok Google, Which Customers Do I Need to Talk To Today?

And you might proceed to a more complicated idea, like:

Help me write a white paper to encourage more people to try my software today who match the “Small Business” segment.

In a few simple questions that you answer about your business you could determine what to do next, understand how things are going, and earn valuable insights you might not have anticipated.

Meh – you say – not possible. Objectives and key results are based on multiple variables that are difficult to correlate effectively. The metrics they are based on do not collect themselves. In addition, how would you isolate the behavior that drives these metrics?

This is a human-centric way of thinking. Because we’re used to the idea that machines are dumb calculators or not yet capable of building models to make the kinds of decisions we make every day, we discount the future that might happen if we create a model for decision-making that we train every day. Continue reading →

0
Product Strategy, Product Thoughts

(Almost) Everything is Now Self-Service

Posted on by gregmeyer

warby

If you’ve used Facebook for a while, you’ve probably realized that the the promoted ads in the right hand rail are getting more effective. For years I vowed not to click on those ads. And yesterday, I caved, and clicked an ad for Warby Parker glasses. I’ve visited this site before, and have even contemplated using the “Try at home kit” to select a pair of eyeglasses.

This time was different – with prescription in hand and my existing pair of glasses to guide me on sizing, I ordered a new pair of glasses in about 10 minutes. Transaction complete! Only after I finished and I received an email from Warby Parker asking me to take a photo with my computer to calculate a measurement not included in my prescription did I realize how mind-blowing this whole process is today.

In the olden days (pre 2012 or so), you had to go to an optician, get an eye exam, purchase from that optician (or ophthalmologist) and wait several weeks to get your glasses. You could go to Lenscrafters, Costco, or another on-site lab to get faster service, but at a cost of quality. Getting quality eyeglasses with a custom prescription and your choice of frames and colors is now a process you can complete from your smartphone in your house (or maybe even in a coffee shop in the time it takes the barista to make your drink). Let that sink in.

We are now our own service delivery for many transactions that we make. Whether that’s a good thing or not probably depends upon your perspective. For many types of buying this is fantastic – you can shop at 3am! And for other types of buying where in the past you might have needed expert advice you now get the expert advice of … an automated process. I’m not a luddite by any means but think we might be missing something here in the endless desire to control cost and maximize customer choice.

Continue reading →

0
Product Thoughts, Startup

The Minimum Viable Feature

Posted on by gregmeyer

minViableFeature

You’ve been there. A customer asks for a thing they consider to be an easy ask and it’s not in the current product. It might actually be easy or it might be quite hard – you don’t know yet (and you have a sneaking suspicion for one or the other).

You could say “no, not ever”, or “not yet”, or “absolutely – we’ll do it for you” – there are lots of ways to solve the request side of this equation. Those solutions, however, are intimately linked to the way you go about developing your product features.

Committing to building a feature – whether it’s something you intended on building anyway or whether it’s a brand new request that fits into that strategy – requires you to define a Minimum Viable Feature. This description should contain a statement of the problem you’re trying to solve, specifically the Job to Be Done, who the feature serves, and the potential impact created by the feature. Your definition also has to be built in the context of the existing technical capability and business direction of the product.

A Minimum Viable Feature is not just the lowest common denominator of the thing the customer wants you to do and the way you want to do it. It is a carefully considered construction that delivers the job the customer wants to accomplish while laying the groundwork for how similar customers might also want to use that capability in the future. If you put your Future You hat on, you might say that the best feature design helps anticipate and address the future challenges you’ll have while not making people wait until you get there to get 80% of the benefit.

Let’s say you were building an app that let customers tell you about a home improvement problem and you wanted to get as much detail as possible from them so you could accurately estimate the issue. The simplest solution? Ask them to tell you about the scope of the problem, and perhaps take a picture of their leaky sink. The most complicated solution? Take a video of the sink and automatically diagnose the problem. The Minimum Viable Feature version of this might be a highly targeted survey that walks you through the most common problem areas of a specific home improvement area and then instructs you how to take the most helpful video or picture of a specific area to get the maximum input for your effort.

Your version of the Minimum Viable Feature will differ – but the key is to deliver enough functionality and fidelity to the job the customer wants done while building a path to the future of this feature. The more often you do this and the more specific you are about the customer, the benefit, and the way you’ll know if you’ve succeeded or failed, the closer you’ll get to that ideal.

0
Product Thoughts, Uncategorized

Write Down Your Goals

Posted on by gregmeyer

goals

If there’s nothing else you remember from this post, spend 15 minutes writing down your goals for your next project so that you explain them better to the people who matter. The simple act of writing down your goals is a powerful organizer for you, the people you are interacting with in your project, and the people you want to benefit.

Build the Big Picture

When you paint the picture of a problem, a high-level reason why that problem needs to be solved, and a proposed end state that is a great start. That statement doesn’t explain the How, or the resources and tactics you use to get from “project not done” to “project done” within a known amount of time and effort.

So spend a few minutes writing down the ideal state and how you want to get there. Your way will probably be different than mine, which follows a template of prompts. STOP and go do that, then come back.

It seems silly to focus on such a small goal, because knowing what you’re going to do for your project, feature, or idea is obvious.

Isn’t it? 

Test that theory the next time you feel you have alignment on “what is my project” or “what is my feature” by asking someone else to tell you what they think your project is, what benefits it will deliver, and to state the goal you’re both working to achieve.

When the goal of the project, the definition for that project, and the benefits of that project are clear(er), it’s a lot easier to know where to start.

What does this look like in practice?

Consider this example: “Build a new web site Widget.”

  • If you know: “a Widget is a piece of Javascript code you include in the HTML/Web markup of your web page that runs by itself and renders the look and feel for part of your page using a script loaded from another web server hosted by another company”, you start to get a handle for the definition of the thing.
  • If you know: “we have never introduced a thing like this before onto one of our pages,” you might want to test that results differently to make sure there is no required dependency in your environment.
  • If you know: “we use these things all of the time, and this is a new instance of a thing we do already,” your comfort level will be increased.
  • And if you know: “we have already described the ‘look and feel’ of this widget in the fonts, colors, and information architecture of our website, for example page xyz,” you will have made it much easier to know what the thing is that you are building.

Stating the benefits for your project helps you to understand the measurement  you’ll need to quantify these benefits. Then, find the measurement as it stands today. Yes, it does seem elementary to find a baseline, and you need one to prove that something change. If there is no baseline, state your assumptions and move on.

Getting Started …

In the spirit of a brief solution, I’ll keep this post short too. When you’re ready to make your next project better, set a timer for 15 minutes and write the overall goal, 3 things you want to do toward that goal, a statement for how you will measure your progress, and any questions you have about the project. This simple exercise makes it easier to share what you’re doing, how you’re thinking about it, and how to make progress.

 

0