- Identify what networks to monitor initially
- Define what criteria makes a node the most influential for each network
- Identify the most influential nodes within each social network
- Identify which nodes belong to more than one of the networks
- Also, allow an entity to define what networks have more weight than others
- Rank each node according to influence across entire set of networks
Thursday, June 25, 2009
Mixing it Up: Defining the Corporate Solution
At a high level, solving the corporate issue can be accomplished by performing the following:
Wednesday, June 24, 2009
Mixing it Up: Corporate Perspective
More and more companies are beginning to understand the importance of social networks within their marketing campaigns. I received an email from buy.com this morning with an extensive Twitter campaign. In the case of buy.com's campaign, they focus on existing buy.com customers to extend the invitation and then pull them into Twitter and furthermore require them to become a follower of @buy_com. This enables buy.com to grow within the Twitter network and push new campaigns, as well as have their followers tweet to their own networks.
Now, once they have the followers and retweets, what next? How do they keep their message from being diluted, lost in the shuffle, or from becoming Spam? Companies need to determine the most influential nodes within their network to ensure targeted campaigns that reach as many people as possible but do so in such a manner that the message is not diluted or Spammy, but come directly from a trusted member of the social network.
How do we determine the most influential people within a social network? Well, we can easily define who within our network is connected to the most people. Consider the following image:
While two members of this network have 6 connections, the highest number of friends within this example, they are probably not the most influential. The person in the middle of the graph with only three connections is the sole link between the two subgroupings. This does not necessarily make them the most influential, but is meant to illustrate the concept that more connections does not mean more influence. Even with this determination, many more factors need to be taken into account.
There are several algorithms that are helpful in targeting the key influencers within a social network (beyond the scope of this posting). One limitation of running these algorithms within a network is that they fail to take into account the connections between disparate networks. Defining what edges are key influencers within Twitter that are ALSO key influencers within Facebook is an awesome tool for an advertiser within a corporation. If we can break down the barriers between the individual social properties, the possibilities are endless.
User stories:
- As a company I can determine key influencers that bridge multiple social networks so that targeted advertising reaches as many trusted nodes as possible
- As a social network I can determine key influencers within my own network that are also key influencers within a competing network so that I can bring more nodes into my own social property
Mixing it Up: End User Perspective
In continuing my open source social network project transparency theme, I'm going to post two perspectives with several use cases. The first perspective I'll post is the end user.
As a user of multiple social networks that understands that there exist tons of other networks I currently do not belong to, I have a hard time deciding where to spend my time and effort. The two I use most heavily are Twitter and Facebook.
Currently, I can import contacts from other social networks and online services, however, until I create an account I have no idea.
User Stories:
As a user of multiple social networks that understands that there exist tons of other networks I currently do not belong to, I have a hard time deciding where to spend my time and effort. The two I use most heavily are Twitter and Facebook.
- Twitter - Allows me to connect with my followers on mostly non-personal conversation, instructional items and interesting tidbits as well as find others with similar interests.
- Facebook - Allows me to connect with trusted friends and colleagues and post personal comments and updates.
Currently, I can import contacts from other social networks and online services, however, until I create an account I have no idea.
User Stories:
- As an end user I want to be told that a friend in one social network belongs to another social network that I am a member of so that we can connect in multiple mediums.
- As an end user I want to be told that a friend in one social network belongs to another social network that I am NOT a member of so that I may join and connect in another medium.
Tuesday, June 23, 2009
You Need to Mix it Up
From Thesaurus.com:
'..in a mixture, the combined elements lose their individual identities and are fused, blended, or compounded in the result; in a mix, the elements, though combined, retain their individual identities.'
My next opensource project is currently in the planning stages. The idea is to help identify the connections between diverse social networks. I plan to run this project in the open (think 'transparency') so I can learn from my mistakes as well as get input from the Internet community as a whole. More to come over the next few days...
'..in a mixture, the combined elements lose their individual identities and are fused, blended, or compounded in the result; in a mix, the elements, though combined, retain their individual identities.'
My next opensource project is currently in the planning stages. The idea is to help identify the connections between diverse social networks. I plan to run this project in the open (think 'transparency') so I can learn from my mistakes as well as get input from the Internet community as a whole. More to come over the next few days...
Monday, June 22, 2009
Understanding User Stories
I recently had a co-worker ask me the best way to go about creating user stories, so I pushed them to a presentation by Mike Cohn. The presentation listed the framework to be applied as well as some theory. The response was "Yeah, we know all that. How do we get the Product Owner to write the stories, or how do we help them write the stories?"
This got me to thinking and after an hour long conversation I think I have some ideas to share:
1. Scrum Product Owner Training is a must, but not always feasible depending on the client environment.
2. Don't expect to hand off the process to your Product Owner. Explaining the process in detail might excite some clients, and be off-putting to others.
3. Before the Product Owner and the Scrum Master know how the other works, I find it easiest to start with Feature Groups and work them down into user stories one at a time. Feature groups define the higher level items that exist within your project/product. Each Feature Group may then be tracked to show progress against requested functionality. Starting at Feature groups allows the Scrum Master to get the ball rolling and soon the stories will flow faster than you can write!
4. Don't Talk Tech! User Stories should be written to solve the 'What' and even 'How', but are not meant to define the underlying implementation. In most cases tasks will define the implementation.
5. Make sure the Product Owner and Scrum Master have time alone to prioritize the stories. Bluesky sessions with the extended team are very beneficial, but block progress on prioritization.
6. Ensure your Product Owner is empowered. If they are not empowered, the user stories process will fail. Prioritization will be undermined. Use the transparent nature of Scrum projects to determine and call out risks with the Product Owner.
7. Especially early on, write the user story framework down and refer to it often: 'As a ____ I can ______ so that _____.' Don't forget the 'so that' as that becomes imperative in the ongoing prioritization process as well as provides clarity for the team.
8. Don't insist that the Product Owner speak to you in user story form. Take notes as the Product Owner talks and then work with them to write the official stories. The process will improve as iterations pass.
Hopefully this helps someone out there who is struggling with a client who is new to Scrum, or who is having a hard time getting the juices flowing!
This got me to thinking and after an hour long conversation I think I have some ideas to share:
1. Scrum Product Owner Training is a must, but not always feasible depending on the client environment.
2. Don't expect to hand off the process to your Product Owner. Explaining the process in detail might excite some clients, and be off-putting to others.
3. Before the Product Owner and the Scrum Master know how the other works, I find it easiest to start with Feature Groups and work them down into user stories one at a time. Feature groups define the higher level items that exist within your project/product. Each Feature Group may then be tracked to show progress against requested functionality. Starting at Feature groups allows the Scrum Master to get the ball rolling and soon the stories will flow faster than you can write!
4. Don't Talk Tech! User Stories should be written to solve the 'What' and even 'How', but are not meant to define the underlying implementation. In most cases tasks will define the implementation.
5. Make sure the Product Owner and Scrum Master have time alone to prioritize the stories. Bluesky sessions with the extended team are very beneficial, but block progress on prioritization.
6. Ensure your Product Owner is empowered. If they are not empowered, the user stories process will fail. Prioritization will be undermined. Use the transparent nature of Scrum projects to determine and call out risks with the Product Owner.
7. Especially early on, write the user story framework down and refer to it often: 'As a ____ I can ______ so that _____.' Don't forget the 'so that' as that becomes imperative in the ongoing prioritization process as well as provides clarity for the team.
8. Don't insist that the Product Owner speak to you in user story form. Take notes as the Product Owner talks and then work with them to write the official stories. The process will improve as iterations pass.
Hopefully this helps someone out there who is struggling with a client who is new to Scrum, or who is having a hard time getting the juices flowing!
Subscribe to:
Posts (Atom)