Loading...
그릿BD
주*********
Assembling top individuals doesn't make a team. This article outlines how to design a small but solid team using three principles—role design, execution autonomy, and communication structure—along with the Quinn and Cameron organizational growth model.
Of Google's countless projects, only about 50% succeed. The company even runs a unique space called 'The Google Cemetery' that displays tombstones of discontinued services. Google dissects these failures like autopsying a body, identifying direct and indirect causes of problems, documenting them precisely, and establishing countermeasures.
Open innovation is a paradigm where companies must intentionally bring in external ideas and technologies, share internal assets with the outside world, and create value to survive and grow. In other words, it's about breaking down organizational boundaries and increasing the probability of innovation through active external engagement—clearly demonstrating why 'absorptive capacity' is a core competitive advantage for modern startups.
CODEX 4. A B2B Customer Is Not One Person.
There's a common trap startups developing B2B products fall into. They celebrate after meeting with a user: 'They love our product! This is going to sell like crazy!' But then they meet the team leader and hear budget concerns, then meet an executive and hear about strategic direction, and eventually the project quietly disappears. Why?
Because they mistook the customer for 'one person.' Users focus on their work efficiency, managers on team performance, and executives on company growth. Their needs are all different. Our role is to satisfy each player's needs while simultaneously finding the one 'central problem' that completes the entire symphony.
When there are multiple stakeholders, defining the problem is difficult because each one only talks about their own 'apparent problem.'
An Apparent Problem is the individual pain each stakeholder feels from their own position. A user says, 'This software is too hard to use,' a manager says, 'I can't see my team members' work status at a glance,' and an executive says, 'Our project processing speed is slower than our competitors.'
The Central Problem is the single critical bottleneck that cuts through all these apparent problems. The client company often doesn't clearly recognize it themselves. For example, something like 'The core workflow from order–production–delivery is inefficient.'
When you solve this central problem, the user's inconvenience is resolved, the manager's needs are met, and the executive's strategic goals are achieved. Our real challenge is to connect the scattered dots (apparent problems) into a single line (the central problem).
The 'Jobs to be Done' theory, championed by Harvard Business School Professor Clayton Christensen, provides a powerful lens for seeing through this complexity. The core of this theory is: 'Customers don't buy a product—they hire it to get a job done.'
This theory offers especially powerful insights in B2B situations with multiple stakeholders. Each player in the orchestra tries to hire the same product to get a different 'job' done.
The User hires the product for a functional job: 'I want to reduce repetitive reporting tasks and focus on creative work.' The Manager hires it for a managerial job: 'I want to track my team's work status in real time and predict performance.' The Decider hires it for a strategic job: 'I want to reduce company inefficiency and increase market competitiveness.'
Ultimately, the 'central problem' we need to find is the most important 'job' that all these stakeholders want solved. Our real role isn't to sell individual features, but to define and solve the ultimate 'job' that the entire organization is willing to 'hire.'
The early growth strategy of Slack, today's top collaboration tool, is a perfect example of conquering a buying organization.
Slack didn't approach CEOs or CIOs first. It went after users like developers and designers. Users fell in love with Slack's overwhelming convenience and became voluntary influencers, spreading Slack to their teams.
Team managers (buyers) saw data showing that communication costs dropped and development speed increased after Slack adoption. Finally, deciders approved company-wide Slack rollout to solve the 'central problem' of 'company-wide communication inefficiency.'
Slack succeeded in providing the best instrument to each player, and ultimately changing the performance of the entire orchestra.
Step 1. List the Stakeholders
Don't mistake the one person in the meeting for the entire customer. You must map out the roles of everyone your proposal must pass through before final approval. Identify who the 'users' are who will champion your product, and who the 'decider' is who opens the final wallet.
Step 2. Listen to Each Person's Pain
Meet each stakeholder and listen to their problems in their language. Don't ask, 'What do you think of our product?' Ask things like, 'What's your biggest concern, manager?' 'What work usually keeps you late?' 'Which numbers stress you out most when reporting to the CEO?' Listen to their stories of success and failure.
Step 3. Connect to the Keystone Problem
Among the different sounds (apparent problems) from each player, find the common chord (central problem) that unites them.
'The development team's frequent overtime (user problem), project delivery delays (manager problem), and slower time to market versus competitors (executive problem) all stem from one central problem: inefficiency in the development-deployment process.'
When you can complete this sentence, your product finally becomes a 'solution' for the entire organization, not just a 'feature.'
Created with permission from Brunch writer jaha Kim using [Startup Codex 22] content.
To explore more of jaha Kim's content, visit the link below.