Posted by Tien Nguyen at 09:51 PM in SEO | Permalink | Comments (0) | TrackBack (0)
| Digg This | Save to del.icio.us |
Posted by Tien Nguyen at 12:14 AM in e-commerce, Social Networking | Permalink | Comments (0) | TrackBack (0)
| Digg This | Save to del.icio.us |
Posted by Tien Nguyen at 08:27 AM in Data Center, Trend | Permalink | Comments (0) | TrackBack (0)
| Digg This | Save to del.icio.us |
Posted by Tien Nguyen at 02:43 PM in Leadership | Permalink | Comments (0) | TrackBack (0)
| Digg This | Save to del.icio.us |
Posted by Tien Nguyen at 11:21 PM in Business Model, Social Networking | Permalink | Comments (0) | TrackBack (0)
| Digg This | Save to del.icio.us |
Those the report is almost 2 years old, it gives some interesting facts about (mostly MNC) companies' pay in Vietnam vs. other countries. Key facts are:
Posted by Tien Nguyen at 11:31 PM in Human Resources | Permalink | Comments (0) | TrackBack (0)
| Digg This | Save to del.icio.us |
Groupon is a deal-of-the-day service in North America. According to Wikipedia, the company offers one "Groupon" per day in each of the markets it serves. The Groupon works as an assurance contract using ThePoint's platform: if a certain number of people sign up for the offer, then the deal becomes available to all; if the predetermined minimum is not met, no one gets the deal that day. This reduces risk for retailers, who can treat the coupons as quantity discount as well as sales promotion tools. Groupon makes money by getting a cut of the deal from the retailers.
Here's Groupon's description of the service
Groupon is emerging as a new monetization model for online community and social network. In the following slides, Christian provided a concise analysis of the revenue model and market analysis.
Posted by Tien Nguyen at 08:01 AM in Business Model, Social Networking | Permalink | Comments (2) | TrackBack (0)
| Digg This | Save to del.icio.us |
Posted by Tien Nguyen at 06:22 PM in Trend, Web 2.0 | Permalink | Comments (0) | TrackBack (0)
| Digg This | Save to del.icio.us |
I try to never give a quick, general answer to this question because it is so important and also because there are so many factors that need to be considered.
In this article I wanted to enumerate the factors that I look at in coming up with my recommendation. I have also taken this a step further and tried to prioritize these factors starting with the most critical, although I will admit that sometimes I adjust this ranking depending on the culture of the company.
1. Clear Ownership. So much depends on empowered yet accountable product teams. So to me the top priority always is to make sure you carve out something significant that a product team can truly own and feel empowered to make the changes necessary. This must always be tempered with the awareness that all of the teams are interrelated at some level, so rarely do we have complete control of our resources and our product area, but we do try to maximize for this sense of ownership.
2. Alignment with User/Customer. Please note that I’m not referring here to internal customers or stakeholders; that’s below under alignment with business units. I’m referring here to alignment with the actual customers and users of the site or service. You would be surprised at how far down the list this gets pushed for many companies (mostly due to the strength of the influences below) but aligning with the user and customer has very real benefits for the product and the team.
3. Alignment with Development Team. Product managers and designers generally work with developers every day to get their product ideas built, and when the product organization is not aligned with the technology organization, the result is almost never pretty. You see it when a Scrum team is frustrated because they have multiple product owners to deal with, or when product managers have to constantly fight for resources that keep disappearing. The key is not to drive the product structure around the engineering teams, but rather to work together with engineering to move together into alignment. This usually requires a little give and take.
4. Alignment with Architecture. Related to the alignment with the development team but actually much harder is the alignment with the software architecture. Basically, every architecture is designed around some set of objectives and the result is that some things are much easier to do than others. There are many teams, especially those with very old code-bases, where minor things can take a disproportionately long time, and/or require changes across many different areas, and it’s usually because the team is fighting the architecture. Modern architectures improve this characteristic, but even in the best of cases, there will be implications on the product team structure that stem from the architecture. Again, this is a balance. You don’t want the architecture to drive the product. On the other hand, realize that evolving the architecture to better enable the way the team wants to work can be a very significant undertaking.
5. Alignment with Business Units. The fact that this is last on the list will doubtless cause some grief with some business unit leaders as this is typically the highest weighted factor by most organizations, but in my view that’s often a big mistake. There’s an old saying that if you want to know the politics of a company, just look at the web site. The reason this is true is that so often the product organization structures around the business units (rather than the user or customer). If the business units are organized around the user or customer then this is much less of a problem, but more often they are organized instead around other factors like function or revenue streams. It is nice when the user, technology and business units all align, but there are often good reasons why this is not the case, and if that’s the situation you are in, I advocate aligning the product first around the user, then technology, and finally the business unit.
Notes:
- This entire discussion relates strongly to the dedicated team model and also to the development process the team is using (especially true with Scrum). Moving to dedicated teams and using a modern process such as Scrum will force some of these issues and in most cases help considerably in the above alignment objectives.
- Realize that the optimal structure of the product organization is a moving target. The organization’s needs should and will change over time. It’s not like you’ll need to reorganize every few months, but revisiting your structure every year or so makes sense.
- For larger teams especially, it is very common to have one or more teams that provide common services to the other product teams. Often we call these teams “common services” or “core services” or “platform” teams. This is extremely high-leverage, but also among the most difficult types of product teams because of the technology, the dependencies, and the wide range of users. Be sure to staff these common services teams with strong and technical product leaders.
Finally, realize that there is never a perfect way to structure a team – every attempt at structure of the product organization will be optimized for some things at the expense of others. So as with most things in product, it involves trade-offs and prioritization. Hopefully these factors will help you as you guide your organization forward.
Posted by Tien Nguyen at 06:10 PM in Organization, Product Management | Permalink | Comments (0) | TrackBack (0)
| Digg This | Save to del.icio.us |
Technology is propagating new, equally powerful forms of multisided business models. In some information businesses, for example, data gathered from one set of users generate revenue when the business charges a separate set of customers for information services based on that data. Take Sermo, an online community of physicians who join (free of charge) to pose questions to other members, participate in discussion groups, and read medical articles. Third parties such as pharmaceutical companies, health care organizations, financial institutions, and government bodies pay for access to the anonymous interactions and polls of Sermo’s members.
As more people migrate to online activities, network effects can magnify the value of multisided business models. The “freemium” model is a case in point: a group of customers gets free services supported by those who pay a premium for special use. Flickr (online storage of photos), Pandora (online music), and Skype (online communication) not only use this kind of cross-subsidization but also demonstrate the leveraging effect of networks—the greater the number of free users, the more valuable the service becomes for all customers. Pandora harnesses the massive amounts of data from its free users to refine its music recommendations. All Flickr users benefit from a larger photo-posting community, all Skype members from an expanded universe of people with whom to connect.
Other companies find that when their core business is part of a network, valuable data (sometimes called “exhaust data”) are generated as a by-product. MasterCard, for instance, has built an advisory unit based on data the company gathers from its core credit card business: it analyzes consumer purchasing patterns and sells aggregated findings to merchants and others that want a better reading on buying trends. CHEP, a logistics-services provider, captures data on a significant portion of the transportation volume of the fastest-moving consumer goods and is now building a transportation-management business to take advantage of this visibility.
Not all companies, of course, could benefit from multisided models. But for those that can, a good starting point for testing them is to take inventory of all the data in a company’s businesses (including data flowing from customer interactions) and then ask, “Who might find this information valuable?” Another provocative thought: “What would happen if we provided our product or service free of charge?” or—more important, perhaps—“What if a competitor did so?” The responses should provide indications of the opportunities for disruption, as well as of vulnerabilities.
Posted by Tien Nguyen at 10:58 AM in Business Model, Trend, Web/Tech | Permalink | Comments (0) | TrackBack (0)
| Digg This | Save to del.icio.us |
Recent Comments