Editorial diagram of the ideas or workflow discussed in this article. It is a schematic, not measured data or a product screenshot.
Indigo, in conversation with Yuzheng Sun. Edited account of the 2025-05-02 video, focusing on 03:31–09:30. This is a thematic article, not a verbatim transcript.
A product’s early history often becomes tidier after it succeeds. Indigo’s account of the work around Weibo is more contingent: an earlier technology business, an acquisition, pressure inside a larger company, a small team, and an operations organization able to bring people onto the product.
The conversation is useful because it separates several contributions that a single founding story can compress. Building the software, establishing the audience, committing resources, and creating an organization capable of competing are related tasks, but they are not the same task.
Existing work can become the starting material
Indigo describes an early software business and a later company working on distribution for rich-media electronic magazines. Sina acquired the technology and brought in the engineering team. The move placed people with practical product and systems experience inside a much larger media organization.
When social networking created pressure on Sina, the team did not begin with a blank page. Indigo recalls working with the blog product and elements of an internal social product that had not launched. A microblogging feature became the basis of the new project.
In that account, the opportunity depended on recognizing what existing components could become in a changed environment. Reusing technology did not settle the product decision, but it made a rapid response possible. A small team could act on an opening without rebuilding every underlying capability first.
Product and distribution did different work
Indigo recalls leading a team of roughly a dozen people through the early build. Alongside the product and engineering effort, Sina’s operations team helped bring users and public figures into the service.
That pairing matters. A working product still needs activity that makes it worth returning to. A media organization’s relationships and operating experience can help solve a problem that code alone does not address.
The account does not reduce the outcome to an incumbent’s resources. The product team still had to identify the opening and build quickly. Nor does it present a small team as sufficient by itself. The combination joined focused execution with capabilities that were already distributed across the larger company.
For a builder evaluating an internal opportunity, this is a useful way to examine the parent organization. Which strengths would actually help the new product? Which ones can the team use without inheriting every part of the existing process? The answer is more specific than whether a large company is generally good or bad at innovation.
A project can outgrow its original arrangement
As competition increased, the organizational arrangement changed. Indigo describes the decision to establish a separate company, make a larger financial commitment, and issue a new set of incentives. Some employees preferred the familiarity of staying inside Sina; others moved with the project.
The new structure gave the work a different degree of independence while continuing to draw on resources from the parent. In his telling, the change affected practical details as well as formal ownership: the team, the office, and the sense of responsibility all shifted.
The episode makes organizational design part of the product story. A structure suitable for testing an idea may not be the structure that supports the next competitive phase. Resources and incentives must catch up with what the project has become.
This is a recollection of one company’s path, not a formula for reproducing its result. Its value lies in the separate pieces it makes visible: existing technical work, a focused team, distribution capabilities, and a willingness to change the organization when the project demanded more.



