Applications that improve knowledge worker productivity have to satisfy “prepared users” not “casual users” and are especially challenge to do customer discovery and development for. With his permission, I have included William Pietri (LinkedIn williampietri) answer to a real question from an early stage entrepreneur because I found it incredibly insightful. I have known William for the better part of a decade now, he is a very clear thinker and and excellent writer and I always learn something from his writing.
Q: How to Explore an MVP For
Knowledge Worker Productivity
I have done several e-commerce businesses and am preparing to start my first “innovative” company to improve knowledge worker productivity. My first though was process automation that would allow certain types of teams to build a process that encourages them to do quality work–nothing slips through the cracks. The more I’ve thought about it, and the more potential customers I talk to, the more convinced I am of the idea. However, given the variety of actions that can be part of a process, I’m unsure how to pick the right action to automate first.
For example, should I start by
- Automating the scheduling of meetings?
- Providing guided workflows to use during those meetings?
- Integrating with existing tools to get information to guide customers down the right paths in their meeting discussions?
Each of these aspects comes with
- its own set of competitors,
- its own relative value to customers,
- its own level of difficulty to implement competently,
- distinct onboarding challenge: for example customers might be more scared to use a tool that requires their whole team to get on board, vs one where they can get value when using the tool alone at first.
With all these aspects to trade-off, does anyone have advice on determining which of multiple possible MVPs to start with?
Also, I’ve noticed that lots of startups are laser focused on just one of these aspects and improving the experience of that stage of the process. But it’s hard to be laser-focused on automating the overarching process that cross-cuts all those stages, which is what I really want to do. Am I aiming too high, even if I start with just one stage or aspect? Otherwise, why haven’t these other businesses expanded out of their niche yet?
Thanks for any advice!
William Pietri’s Perspective
The point of experiments is to test hypotheses. MVPs are especially important experiments because instead of testing the demand for a product (as with, say, a landing page), we’re testing that the imagined product really delivers enough value for people that they keep using it.
One fear I have from your description is that you are solving a problem that you see, but maybe your customers don’t see it.
So, in your shoes I’d go very carefully over my previous interviews and see where people have expressed their greatest pain related to process automation. I’d look for ways some of them have come up with half-assed solutions themselves. Then I’d pick a focused group of those people and make something very specific for their needs.
Your point about people being laser-focused on one aspect of the experience is definitely important. This could say something about actual needs: people may value excellence much more than they value integration. It could say something about purchasing: it can be easier to sell to individuals or small groups at a company than to get everybody to agree on the same thing. Or it could say something about ripeness for impending change. Google Docs was not “better” than its competitors, like Word or Keynote. But having them all online made a huge difference. Smartphones and Swiss Army knives are both huge compromises over any individual device they replace, but having everything together can be better than “better”.
Given that, I can see three plausible paths forward (and I’m sure there are more):
- Start with integration, a pure connector of things;
- Start with one tool, but one with integration out of the gate; or
- Start with simple, integrated versions of key tools, selling to people who don’t really use any competitor tool.
I don’t think there’s a clear right one to start with in the abstract. If you’re familiar with Crossing the Chasm, you know that most adoption comes through social proof.
I think a key question is, “Where can you most easily build a customer base?” Hopefully one of those will be good for an MVP that tests your central hypothesis about integration. If you have several good options, then you can start ranking them by other factors:
- revenue,
- ease of growth,
- marketing value,
- ease of moving into other segments.
And when I say “you” I really mean you. The theoretically correct place to start doesn’t matter much; this is all about what you can accomplish.
There’s one caveat I’d like to add: it’s very easy to look at the behavior of a bunch of people and say, “Oh, this could be so much more efficient!” My friend was working on a task management system, and almost every potential customer they talked to said that
- they struggled to manage tasks well, and
- they’d be happy to pay for something that was better.
It turned out, though, that different people work differently and what each person wanted from a “better” system was different in ways that were often conflicting. Even more so once they went beyond individual tasks. So I now encourage people to be sure that they aren’t overgeneralizing: just because we as outsiders describe what many people do using the same terms doesn’t mean that they really form a coherent market for a single solution.
Entrepreneur Response to William Pietri
Thanks a ton for your reply, William! It’s much appreciated. You addressed a lot of the concerns I had and you’ve helped me visualize a path from where I am to the MVP.
I think, based on your feedback that I should be doing more customer outreach to choose a specific pain point to address. I don’t think I’ve talked to enough people just yet to really understand which aspect of the problem is most painful. I should also be focusing on how a single person can get value out of the product without having to get agreement from everyone else on the team right away, so that onboarding isn’t so scary.
Re: your caveat. That is definitely a concern here, and one of the reasons I don’t think this has been done before. But the more people I talk to, the more similarities I am seeing, at least at key points that will let me build a generalized product.
Thanks again for taking the time to respond. I really appreciate it!
SKMurphy Perspective
Let me second William Pietri’s suggestion:
“One fear I have from your description is that you are solving a problem that you see, but maybe your customers don’t see it. So in your shoes I’d go very carefully over my previous interviews and see where people have expressed their greatest pain related to process automation. I’d look for ways some of them have come up with half-assed solutions themselves. Then I’d pick a focused group of those people and make something very specific for their needs.”
Measure the cost of your system as the depth and breadth of behavior change prospects anticipate that they must endure to get some value out of the system. There is a threshold effect such that changes above a certain size, unless an organization is facing a “near death experience” are very hard to effect. And even then, many firms may choose to go out of business. The key to implementing a large vision for radical system-wide change is to break it up into many small steps, each of which “pays for itself” in time savings or dollar savings, or risk reduction so that people can follow a “trail of stones across the creek” instead of trying to leap across in one go.
You wrote
“I could start by automating the scheduling of meetings, or by providing guided workflows to use during those meetings, or by integrating with existing tools to get information to guide customers down the right paths in their meeting discussions.”
When I read this description of the problem you want to help your prospect solve it sounds very very diffuse. It mixes a potential methodology change with technology changes: it’s normally better to get agreement on process or methodology, work through “by hand” and then start to provide more automation.
In particular making meetings more effective involves a complex mix of social protocols, collaborative approaches to problem solving, and key enabling technologies. Arguably the last few technologies that have made a difference are:
- the table to act as a platform to review and comment on a document or drawing
- the blackboard, later whiteboard, later shared display to enable joint annotation
There is a lot going on that may not be captured in the artifacts that result, in the same way it can be difficult to infer the tooling and manufacturing process form a finished good. Complicating matters further there many types of meetings with different objectives. Here are three categories, I am sure there are several I have overlooked
- communicate / inform
- coordinate / seek advice and input
- frame / identify constraints / agree on problem to be solved or decision to be made
- collaborate / participate in the decision
Worse, what from some perspectives looks like waste–e.g. letting everyone share their perspective on a situation that many will later modify/abandon in favor of a working consensus–can be an important part of the decision-making process.
Fundamentally I agree with you that subjectively it seems like there is a lot of wasted time and effort in meetings, but it may be as much a methodology problem, a social process challenge, and a question of incentives as it is one of missing technology. My personal focus has been on experimenting with different ways to foster shared note taking so that a rough consensus gets captured along with the various paths that were explored.
Before I would write any custom tools, I would investigate what methods, social process, and tools high performance teams use and where they are looking for help. It can often be easier to help someone who is going fast who wants to go faster than to engage with a team that’s stuck at the starting line–the latter may have many problems that need to be addressed before they can start moving forward. Normally teams trying to improve are already trying many things and can integrate new approaches more easily as experiments than a team that is stuck and would seem to have greater need.
Entrepreneur Response to SKMurphy Perspective
Similar to William above, you’ve mentioned an aspect that I need to consider – how can I lower the cost of my system/required behavior chance vs the value it provides. I’ll keep that in mind.
Re: your suggestion to “work through by hand”, I think that’s an excellent point. I’m probably jumping the gun a little bit and will need to talk to more customers to make sure that what I would do “by hand” matches what they really want, before I start automating it. I’m leaning toward the methodology changes being the central part of the MVP (rather than the bells and whistles of integration and automation) because they will validate the core benefit most.
I also want to thank you for the detailed thoughts on types of meetings, problems with meetings, and various use cases for meetings. I haven’t read much on the general topic of meetings, but I think I should (so thanks for the links!).
To your point about it being easier to help the fast go faster than to help those at the starting line – that is some excellent insight! Thank you!
From talking to some companies that are attempting to undergo this transformation already, it seems they usually come about through a proactive champion who is keen to experiment and shares their new learning with the rest of the team. They lead the charge. Based on your insight, I’d probably want to focus on helping that person achieve their goals – they’ve already gotten started.
Thanks again for your post!
Blog Posts Related to Knowledge Worker Productivity
- Don Reinertsen: Priorities Are the Last Refuge of the Innumerate
- Three Key Features for a Webinar or Conference Call
- Priorities Trump Productivity
- Lisa Solomon on Effective Meetings: Choose One of Reaching Understanding, Generating Options, or Making Decisions
- Are You Using Realtime Shared Document Edit Tools? Let’s Compare Notes
- Labor Day 2014: Knowledge Worker Productivity
- Embrace Parkinson’s Law as a Constraint
Licensed image (c) rawpixel