Tag: product development

Thoughts on the Bus Problem

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.

0

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


(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

It’s not enough to build a beautiful site

photo by http://www.flickr.com/photos/stasiland/

“It’s about people.” –Marcus Nelson

Marcus Nelson’s blog post today about the potential for creating a renaissance at familiar names like Flickr, Digg, and Yahoo challenged me to think about the internet services that I actually pay for (and don’t just use as a beta customer) and the critical differences between these “gotta-have-it” products and the rest of the Internet chaff that’s easy to try these days in an almost zero-friction way thanks to the power of social login (which reminds me, I’ve got to clean up my Facebook and Twitter authorization.)

Sorry Design Hackers, Design is Not Enough

Marcus’s axiom that “it’s all about people” is a powerful one because it’s not enough to build a beautiful site (or app) these days – you also have to build a habit that allows people to learn and practice a known process that brings them tangible benefits. Yes, you say, great design is necessary for great apps (I agree). I also think that it’s not sufficient to have a beautiful design where the principal message to new users that don’t get it is “you didn’t do it right.”

Great Apps Start with Unmet Needs – and Fill them

A perfect example of a service that’s both well designed, beautiful, and deadly accurate and functional is Sanebox. We all have the problem (or at least most of us do) of having too much email and not enough time to deal with it. And an even greater problem is the inability to know which emails are likely to deserve our attention. Enter Sanebox – it takes this unmet need and addresses it with an elegant solution – categorizing the mails you see into filters that allow you to scan and review your mail (and bacn) easily. Do I have other solutions for this problem? Yes. Do I pay for Sanebox? Yes.

A Great Need, Unmet

As Marcus points out when talking about some of the “original” internet apps like Flickr, Digg, and Yahoo, they have stagnated because their customers still have great, unmet needs, and have moved on to other services that offer adjacent substitutes (and oftentimes leapfrog innovations). I started using Instagram because it was an easy way to share photographs in a social way – and it offered a fun way to manipulate images that was easy and satisfying. I stayed with the service because it’s still a lightweight way to share photographs. I – like Marcus – still subscribe to Flickr Pro – and I’m wondering why I still do. If Instagram were to offer me an easy way to archive photos (perhaps through Dropbox) and gave me a way to upload non-square images, they would have me as a customer (until the next big thing comes along.)

People are Sometimes Stuck, but that Doesn’t mean you should stop innovating

People resist change (or I wouldn’t still be a Flickr Pro member, obviously) for lots of reasons. But that doesn’t mean that your product should stay the same. Keep building the features that people use (and get rid of the ones they stop using) and you’ll be farther along the path of building an innovative, interesting product that people compelled to pay for, even when new and shinier products come along.

0

The Product You Deliver Will Change – Agile Marketing Principle #2

ahhh
photo by http://www.flickr.com/photos/javierbravo/276681175/

Build your marketing plan so that the “Oh that changed” moment doesn’t derail you – Agile Marketing Principle #2

Have you ever started a project assuming that the end product you were delivering would look exactly like the original specification? Yep, everyone’s done that once (or twice) and then realized that the process of product development lends itself to greater certainty the closer you get to the delivery date – and not before. It would be great if agile development always delivered the results of the original team’s vision. The second principle of Agile Marketing is to build your marketing plan with the knowledge and expectation that your product deliverables will change – and to not let the “oh s$%^t” moment prevent you from being successful in communicating and delivering value.

The Product Process: Capturing Rainbows and Unicorns

It’s easy to think that the first (or even second) iteration of a project will somehow emerge, full-formed and testable, feature-complete and pixel perfect, at the time that development teams, product managers, and marketers agree. And this turns out to be about as easy as procuring unicorn hairs or gathering gold at the end of a rainbow – because the real product that gets delivered is a product of the process, the people, (and the users, if they are lucky enough to use the product during this process.) in the digital world, where the prototypes are usually built in someone’s head or delivered as sketches rather than physical products, the gap can be bigger and unexpected. What’s a marketer to do to mitigate this product shift?

Products provide solutions to customer needs – sell those needs

Any product worth its salt provides a tangible solution for an unmet customer need. Dropbox solved the problem of being able to share files across desktops. Stubhub allowed customers to sporting events and concerts to buy tickets more efficiently on the secondary market, and for season ticket holders to sell their unwanted inventory. Twitter gave people a mouthpiece to speak to the entire world (albeit in very small 140 character bursts. And all of these products didn’t end up exactly as their creators expected originally. Selling the customer’s need (resolve an immediate work process pain; access unwanted and “secret” inventory; and share news with the world) gave the marketers of these products a broader brush to sell the idea until the product caught up.

Focus on the activity that will address those needs

Simply selling an idea falls flat if there is no specific activity that delivers on the promise of the idea the product is selling. In the previous Agile Marketing post on delivering what people need, we talked about an end-user benefit – the specific thing the customer will get by using your product – and how critical it is to selling the habitual use of your product. Your marketing plan needs to focus on the activity that addresses the customer’s needs, and educate the customer directly on that benefit.

Build the marketing campaign off of the “Paper Prototype”

What’s it going to look like? During the design process, you should have built a “paper prototype” – or some sort of approximation of the eventual functionality, user experience, and feedback the user receives when using your product.  This prototype gives you a design idea (what you’re selling), the end-user benefit (why the user wants to use this product and the motivation for continuing to use it) and the user experience (what they will do and how they will feel while using it.) These are all emotional reactions that you can harness in your marketing plan that won’t change even if the product experience is a bit different than that original paper prototype.

Put in place a good feedback process to understand where you missed

Except that sometimes, the product does change in a way that’s contrary to your original marketing plan (even if it’s agile.) So part of your marketing process needs to be intelligence gathering that can foster a continuous improvement process matching how the customer feels about the end-user benefit you’re selling, and how well your product lives up to that promise. Agile marketing responds to this uncertainty by focusing both on the deliverable and on the problem solved by the deliverable, leaving “wiggle room” if the team slips or weird things happen and opportunity to expand if everything goes perfectly. If you talk about a specific feature that you will deliver, you’re in trouble if you don’t ship – if you talk about solutions to a customer problem, you have more room to adapt.

Tweet this

1

Deliver what people need – Agile Marketing Principle #1

Build Customer Satisfaction by Delivering Rapidly – Agile Marketing Principle #1

What do your customers ask for (either from a product or product marketing perspective?) Chances are, it’s not always what they need. In this second post on Agile Marketing, I’m thinking about ways to deliver what your customers need, not just what they ask for at the moment.The first principle of Agile Marketing is to build customer satisfaction and market acceptance by rapidly delivering solutions that people ask for and need.

Agile Marketing, as we discussed previously, is a process to:

“Create, communicate and deliver unique value to an always-changing consumer (or business) in an always-changing market with an always-changing product.”

What do your customers ask for

Customers often ask for the thing that’s on their mind at the moment – and the best customers also consider some of the ways they might use a feature or service in the future – to solve the problem that they have at hand right now. This might be a reasonable request (can you move the doohickey a few pixels to the left) or a less reasonable request (we really need to make this work in a case we’ve never seen before, but are worried that it might happen.)

What do they need

But wait. Remember, you are not the customer – you’re simply helping them to share their requirements in a way that makes sense to them and communicates value to your organization – so the “unreasonable request” might actually not be so unreasonable. To find out what they really need, ask a few questions:

  • Who will use this feature?
  • What are they trying to accomplish?
  • Can they do this today, and is there any alternative way to get this done?
  • Are there other places you’ve seen this type of feature, and where can I find them?
  • How will the user know that they’ve been successful?

This may seem to some to conflate the process of marketing and product development, and I believe that customer-driven product marketing needs to start with an understanding of what the customer is trying to accomplish, and then move to the product definition that will accomplish that vision.

What makes sense to build (and when) – start with a statement of end user benefit

Starting with a statement of customer end benefit is an excellent way to share these findings with your product development team (or, of you’re also the product development team, to establish a clear goal for the improvement you’re trying to make.)

This is actually pretty simple, and should look like:

[my customer] uses [my feature ] to [accomplish a goal] and knows when they have have accomplished their goal when [what happens]. The feature is relevant to the rest of the product because [why is this feature not a one-off], and the customer will use it [how often]

If you can write out this statement for the customer (and it doesn’t sound ridiculous),  you’ve started to create your messaging points to the customer and to the internal team.

How do you deliver it – statement of end user benefit

Now comes the challenging part: how do you deliver this solution quickly, while maintaining fidelity to the end user benefit statement and also not driving your internal team crazy with spurious requests? One great way to start is to build a “PowerPoint prototype” (thanks @tamccann for the inspiration) which demonstrates how this idea might work. Then, test it with both your customer and a sympathetic member of your development team. You should get some good ideas, some questions you haven’t thought of, and some possible options to deliver the idea to the end user.

How to know when you’re succeeding

Make sure that your end delivery fulfills the user benefit statement – when it does, and when you’re able to deliver it rapidly, you’ll be closer to the goal of delivering solutions that the customer wants within a time frame they can live with. Note that the goal is not to shove poorly realized solutions out the door – it’s to understand what the customer wants, identify some options that may solve that want and validate it as a true unmet need, and to get the 80% solution out into the wild so that customers can use it and provide feedback.

Tweet This

8

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: