How to Improve the Efficiency Value of Tool Platforms?

Preface

The previous article How to Measure the Efficiency Value of Tool Platforms? derived a measurement model, measuring efficiency value through specific data indicators, making the value of internal tools/platforms visible and explainable

So, for tool platforms that are being built or will be built, how to further enhance their efficiency value?

I. What Factors Affect Efficiency Value?

First, the key goal of tools is to solve practical problems:

Tools are always born to solve problems

After selecting the target problem, then try to solve it through automated/semi-automated means such as toolization and platformization, and reflect the efficiency value of the solution through improvements in both efficiency and experience:

Efficiency Value = Efficiency Value * Experience Factor

Further refinement:

Tool Efficiency = Problem Scale / Operation Time
Tool Efficiency = Time Cost (without using this tool) / Time Cost (using this tool)

Tool Experience = Ease of Use * Stability

Therefore, the efficiency value of a tool depends on 4 factors:

Problem scale
Operation time
Ease of use
Stability

Improving tool efficiency means finding ways to increase the numerator and decrease the denominator, i.e., increase problem scale, ease of use, stability, and reduce operation time

II. How to Increase Problem Scale?

For a selected target problem, its scale is usually fixed, so the key lies in how to choose the problem with the highest target value:

Target Value of Problem = Target User Count * Demand Frequency * Single Value

In most cases, we tend to choose problems with larger target user counts, because solving a commonly existing problem is more meaningful than solving a special problem that only a small group of users will encounter

However, the impact of demand frequency and unit price on target value is not so obvious:

[caption id="attachment_2293" align="alignnone" width="625"] High Frequency Low Price vs Low Frequency High Price[/caption]

Among them:

First choice: High frequency high price: Very rare demand, if available, prioritize satisfying
Don't do low frequency low price: Such demands are not worth doing
High frequency low price and low frequency high price equally important: Most demands fall into these two categories, and choices are concentrated here

Between high frequency low price and low frequency high price, the general strategy of product managers is:

High frequency captures users, low frequency makes profits

That is to say, in the early stage, first obtain a large number of users by satisfying high frequency low price demands, and consider low frequency high price demands in the middle and late stages:

First use high frequency low price demands to capture users, because high frequency scenarios have more opportunities to interact with users, and low price light decision scenarios can lower the user entry threshold, making it easy to attract new users and drive traffic; then use low frequency high price demands to make profits, because when the unit price is higher, the cake that can be cut is larger. The reason for adopting such a sequence is that there must be a massive user base as a foundation for the total volume of low frequency demands to be large enough.

III. How to Reduce Operation Time?

Of course, if there are obvious items to optimize, they should be done as soon as possible, first raising the tool's own efficiency to a fairly high level, reducing the time users wait for the tool to complete its operation

But if the tool itself has no much room for optimization in terms of time consumption, then it's necessary to shift the gaze from the local tool and consider overall optimization from a global perspective:

Process-oriented perspective: In terms of process, can some intermediate links be reduced and the workflow simplified
Object-oriented perspective: In terms of pattern, can the relevant roles involved be reduced, reducing interactions between people and tools, tools and tools, tools and people, and reducing some intermediate products

Changes in processes, or even collaboration models, usually have the opportunity to subvert the critical path of solving problems previously, bypass the efficiency bottlenecks of existing tools, thereby significantly reducing operation time

IV. How to Improve Ease of Use?

The first priority of tool-type products is that users can use them. Let users at least know how to use them before the product's value can be reflected

Ease of use requires product functions to match user mentality as much as possible (at least ensure the ease of use of core functions), simplify interactions, and reduce the learning cost for users to get started:

Mapping from user mentality to product functions, the ultimate ease of use is being intuitive, ready to use out of the box

So, first clarify user mentality. The approach is very simple:

Tell users what specific problem this tool can solve for them.

Then (when product functions are not so intuitive) first teach users how to use it. Function guides, beginner tutorials/videos, help documents, etc. are all good methods, aiming to improve ease of use and get users to start using it first. At the same time, continuously optimize the user experience based on real user feedback, narrowing the gap between product functions and user mentality, making it ultimately conform to intuition:

Low mental burden (low learning cost)
Friendly interaction
Beautiful UI
Smooth core function flow

Besides making product functions align with user mentality, there is also an unconventional approach: cultivate user mentality (i.e., change user intuition to match product functions). This mostly appears in disruptive innovation scenarios. Only by changing users' deep-rooted intuition can efficiency be truly improved

V. How to Improve Stability?

Mapping from user mentality to product performance, the ultimate stability is complete trust, never doubting that the tool will have problems

Compared to ease of use, stability is objective and clear. Stability can be largely ensured from a technical perspective alone, for example:

Reduce crash rate: Continuously monitor top crashes and timely fix those with larger impact scope
Reduce bug count: Continuously observe bug growth trends, quickly iterate and fix, converge functional issues
Reduce operation failure count: Record failed operations, analyze and improve common misoperations, while enriching functions in reverse

Among them, what's worth noting is recording failed operations. Taking search function as an example, failed operations include:

Search service errors
No search results
Search results don't match expectations (results are not helpful)

From a technical perspective, the latter two categories don't belong to operation failures, but they are also worth attention. Because searches with no results usually mean semantic/fuzzy search functions are not perfect enough, or related content is missing. This information is very helpful for enriching product functions. Similarly, search results that don't match user expectations are also a valuable negative feedback, helping to discover problems and improve user experience

VI. How to Increase User Count?

When the tool's efficiency and experience meet the standards, the most critical issue is how to increase user count and amplify the tool's value

Compared to other products, the difficulties of tool-type products lie in:

Strong substitutability
Users don't know (there are tools available to use)
Poor user stickiness, easy to churn

Strong irreplaceability is the decisive factor. As the only option, there's naturally no need to consider user count issues, such as Mini Program developer tools

If strong irreplaceability is not available, other means must be used to increase user replacement costs. Common strategies include scenario-based operations, community operations, content operations, etc.

Scenario-based Operations

Closely associate the tool with usage scenarios to cultivate user habits:

When making tool-type products, you must always ask yourself in what specific scenario users will think of opening your product. This specific scenario is the foundation of all operations

Center around a core scenario, fully satisfy key demands, and become the optimal solution in that scenario, thereby solving the problem of users not knowing

On the other hand, scenario-based warm reminders help increase the product's warmth, letting users feel human care, not just a cold tool

Community Operations

Strengthen the connection between product and users, as well as among users. Building a community is an effective means to improve user stickiness, for example:

Operate a group: Turn the cold tool into a "living person" who can communicate, bringing the product closer to users
Add social functions: Users subscribe to product updates, follow, comment, like among users, increasing users' sense of participation and belonging

Inform users of product changes through groups. This continuous frequent positive feedback can stimulate users' enthusiasm to feedback problems and enhance the connection between product and users

Socialization sounds somewhat distant from internally used tool platforms, but it's actually not far. Taking frontend engineering as an example, common components/code snippets, Code Review, beginner tutorials/API documents, etc. can all have simple social functions (like, comment). Although seemingly small, it helps improve user participation

Content Operations

Like community, content is also a scenario extension. Take the content produced by the tool as part of the tool itself, for example:

WPS and Docer Templates
Git and Gist

Tools guide users to output additional value, thereby enhancing the overall value of the tool (tool + shared content). On the other hand, users sharing generated content with other users also helps enhance their own influence, mutually promoting each other