Tuesday, December 27, 2011
Tuesday, December 20, 2011
Wednesday, November 9, 2011
Timely Harvest, Supporting Product & A Decadent December!
Thank you to everyone who made it to our latest roundtable meet-up of The Product Group at MTV Networks / Viacom, as well as to our sponsors, Balsamiq Studios, Sunshine Suites, and Ryma Technology Solutions.
Don’t forget to send in your nominations for THE BEST PRODUCT PERSON OF 2011!
http://tbpp.wufoo.com/forms/the-best-product-person-of-2011/
Over the course of the night a few of the highlights were…
What would you like to see discussed at the next meetup of The Product Group? Click through to read the article, discuss and share.
Friday, November 4, 2011
Wednesday, October 26, 2011
Oct 31: The Search For The Best Product Person of 2011
Oct 31: The Search For The Best Product Person of 2011by prodmgmttalkJeremy Horn, The Product Guy, Discusses Products, Their Managers, And The Search For The Best Product Person Of 2011
The Best Product Person (TBPP) is the leading international award honoring excellence in Product Management. Established in 2010, the time has come to identify the recipient of the second annual TBPP award. This discussion will be a rigorous questioning of product professionals regarding their products, management and excellence. What are some traits of bad customers and what interventions can improve customer behavior? How do you prevent fixating on lesser product feature(s)? What tips and tools are effective for time management? How do you know when the time is right and what actions to take at end of product life? How to identify the Minimum Viable Product. What characteristics and requirements distinguish the Best Product Person? Might I be The Best Product Person of 2011?
Each week, The Global Product Management Talk features an expert guest speaker who asks questions of the participants on Twitter in a Socratic discussion. The speaker and co-hosts broadcast their comments over BlogTalkRadio. The transcript of Tweets and podcast are available after the live event.
Jeremy Horn, The Product Guy, will be leading the weekly Global Product Management Talk on Twitter Monday, October 31, 2011 at 4:00 PM Pacific Time, which will be Tuesday, November 1 at 10:00 AM Australian Time.
Over the last 10+ years, Jeremy Horn has held various executive and advisory roles, from founder of his own network security, intrusion detection start-up in the late 90's to leading and advising diverse start-ups (in online services, consumer products, social networking, etc.). Jeremy Horn was awarded an AlwaysOn Top 100 award for SingleFeed (a company he founded in 2006). He can currently be found at MTV Networks / Viacom pioneering the next generation of content management and sharing. Jeremy Horn is also the author of very popular The Product Guy blog (http://tpgblog.com) which provides public advice and critical assessments of and for everyone from start-ups to enterprises and their online products. He organizes the 1000+ member monthly gathering of Product People at The Product Group (http://meetup.com/theproductgroup). Jeremy graduated from Carnegie Mellon University with a B.S. in Computer Science.
“I love meeting with product people and am excited about the opportunity to discuss many of these product issues we all care about with the Global Product Management Talk community. I can't wait to provide everyone with the latest on the search for The Best Product Person of 2011 and share how you can participate,” says Jeremy Horn.
- Products, Their Managers, & Search for The Best Product Person of 2011
Join in from any social media, LinkedIn, FaceBook or Twitter - or don't sign in from Twitter at all! http://stanzr.com/prodmgmttalk
http://stanzr.com/prodmgmttalk- TBPP | The Best Product Person
Nominate them here!
http://tpgblog.com/tbpp/- Blog: The Product Guy
Jeremy's Blog: Discussion, advice, and reviews regarding online products, the people behind them and the trends they represent, from Modular Innovation and Product Management to User Experience and Quick-UX.
http://tpgblog.com/- RSVP: Global Product Management Talk on Twitter @ProdMgmtTalk - Eventbrite
Global Product Management Talk presents Global Product Management Talk on Twitter @ProdMgmtTalk -- Monday, October 31, 2011 -- San Francisco, CA Jeremy Horn @TheProductGuy Leads Discussion About Products, Their Managers, And The Search For The (Second Annual International) Best Product Person Of 2011
http://tbpp.eventbrite.com- PR: The Global Product Management Talk On The Search For The Best Product Person Of 2011 | PRLog
The Global Product Management Talk On The Search For The Best Product Person Of 2011. Jeremy Horn, The Product Guy, Leads Discussion About Products, Their Managers, And The Search For The (Second Annual International) Best Product Person Of 2011 - PR11706179
http://prlog.org/11706179
Tuesday, October 25, 2011
How To Build An Agile UX Team
This is the first in a three-part series on how to build and grow successful user experience teams in agile environments. It covers challenges related to organization, hiring and integration that plague UX teams in these situations. The perspective is that of a team leader, but the tactics described can be applied to multiple levels in an organization.
Building any kind of agile team is a lengthy and challenging process. Building a user experience team within an agile organization challenges not only traditional design practices but typical design team dynamics. In this first part, we’ll look at the type of culture that would support a strong UX component in the agile process and how to structure the organization so that designers are most effective and are able to thrive.
[Editor's note: A must-have for professional Web designers and developers: The Printed Smashing Books Bundle is full of practical insight for your daily work. Get the bundle right away!]Organizations Become Supportive Through Dialogue
Teams work together to celebrate their wins at weekly team-wide demos.Critical to the success of any user experience team is an organization that values its contribution. This is not unique to agile shops, but it becomes even more critical given agile’s rapid cycle and participatory rituals. In a typical resource-allocation scenario, no more than one UX designer is assigned to a cross-functional (i.e. scrum) team. In fact, this scenario is usually optimistic. In some cases, a UX designer will be straddling more than one team. “Team” is the core concept of the agile philosophy, and as such it must include the designer as a core member.
Development managers need to set the expectation with their staff that design is critical to the team’s success. As you begin to build your UX practice in this environment, ensure that you have frequent conversations with these managers to review how their staffs are reacting to the addition of designers to their teams. These conversations will help anticipate issues that may hinder the cohesion of the scrum team. In addition, lessons from fixing one of these issues can be applied pre-emptively on other teams.
By the same token, it is incumbent on the UX designer, their corporate champion and team leader or builder to promote the values of the craft in the organization. Again, this is not unique to agile environments, but it is critical to keeping the team focused on core UX and design issues. Key to this promotion is transparency. Let the team into the designer’s world. Let them see what they do and how they do it, and let them experience the benefits that come from doing UX and design work. When all members of a cross-functional team can articulate the benefits of design activities such as,
- speaking with customers,
- understanding the business and competitive landscapes,
- constructing the information hierarchy,
- assessing visual communication,
then they will be far more inclined to carve out time for those activities in each iteration. Include the team in the actual design exercises. By practicing participatory design, the designer’s contribution will become evident, building their credibility and crystallizing team cohesion.
How To Structure The UX Team
Organizationally, there are essentially two ways to structure the UX team: as an internal agency of shared resources or by using a hub and spoke approach, with designers dedicated to specific teams.
Internal Agency Approach
Using the internal agency approach, incoming work is routed through a central point of contact (typically the UX manager) and then assigned to the designer who is best suited to the work and who has the bandwidth to take it on. The challenge with this approach is two-fold.
First, it promotes a culture of specialization in which designers limit their contribution to particular segments of the craft (for example, mobile, e-commerce, social experience design, etc.). Secondly, with no loyalty to the scrum team, priorities become driven by which product owner can yell the loudest, typically leaving the designer in the middle, awaiting the outcome to know where to focus. Additionally, this approach taxes the UX manager heavily by forcing them to constantly assess bandwidth, availability and applicability of skills to the required tasks, all while helping the product owners manage competing needs among the design staff.
Hub and Spoke Model
The hub and spoke model, on the other hand, is the better practice. Dedicate each designer exclusively to one particular scrum team. They should feel like they are a part of their scrum team and feel connected to that team’s focus. In doing so, the designer’s priorities become clear. Their priorities are synonymous with the team’s, thus enabling them to clearly understand where to expend their energy.
Asking for a designer’s input or effort on a “quick” project or “internal need” is a fairly common occurrence in many companies. It is incumbent on your organization’s leadership to protect the one designer or team structure, so that each team’s designer isn’t peppered with these ad hoc requests. Such requests distract the designer from their team’s mission and inevitably consume already limited capacity. In the eyes of the designer’s teammates, these efforts erode any progress that has been made in confirming the designer’s permanence on the team.
Working With The New Teams
New ways of working for designers will, at first, be uncomfortable. For many design managers, assigning their staff to particular teams brings a new challenge. No longer does the design manager dole out specific work to each person on the team. Instead, the designer’s daily agenda is driven by the prioritized backlog of the scrum team. This is a duty that managers were likely used to doing in the past, and its removal may feel like a reduction in responsibility and authority. To fill this potential void, design managers should work with their staff to understand their team’s priorities and suggest methods of structuring the work in a way that allows the best user experience to get built.
Weekly one-on-one meetings with each designer should reveal any challenges unique to their situation. In addition, regular touch points with each team’s product owner will provide insight into any design challenges on the horizon. And monthly high-level retrospective meetings become a forum for managers to share successful and failed tactics across the organization. With all of these tactics in place, the driving goal should be to solidify the designer’s place on each team.
Dedicating your staff to other teams does not portend the doom of the centralized user experience team. The centralized team is still very much needed for mentorship, professional development and general design support (such as critiques). In addition, a centralized UX practice can bring learning from the individual scrum teams back to the broader group, disseminating lessons that improve the process elsewhere.
The centralized UX team also serves as a “safe haven” for designers to vent their frustrations with the agile process, commiserate a bit with their colleagues and reassure themselves that they’re not alone in their agile UX challenges. Weekly UX team meetings are the building blocks of this community. Outings to design events, talks and recreational events help solidify the bond between distributed designers. A UX-only email distribution list or other forum could also provide this safe haven on an as-needed basis and supplement discussion outside of the regular meetings.
Conclusion
Company culture and staff organization are the two fundamental building blocks of agile and UX integration. By creating an environment that values design, promotes its benefits and spreads this gospel through the allocation of UX resources across individual teams, companies will lay the foundation for successful team-building and adoption of the agile process down the road.
In part 2 of the series, we’ll discuss why hiring is such a critical part of the agile UX team’s success and how to maximize your chances of hiring the most appropriate staff.
Friday, October 14, 2011
Thursday, October 13, 2011
Betterment Saving, Product Accelerating & November Harvesting!
Thank you to everyone who made it to our latest, record-breaking, roundtable meet-up of The Product Group at MTV Networks / Viacom, as well as to our sponsors, Balsamiq Studios, Sunshine Suites, and Ryma Technology Solutions who helped us all celebrate our 2nd year anniversary!
Don’t forget to send in your nominations for THE BEST PRODUCT PERSON OF 2011!
http://tbpp.wufoo.com/forms/the-best-product-person-of-2011/
Over the course of the night a few of the highlights were…
What would you like to see discussed at the next meetup of The Product Group? Click through to read the article, discuss and share.
Friday, October 7, 2011
The Rise Of The Virtual Cable Company
The Rise Of The Virtual Cable Company by Dave Morgan, Yesterday, 5:31 PM
SHARE 
TOOLS
RELATED ARTICLES TAGS: Cable TV
MOST READ Yesterday, Microsoft announced that its Xbox 360 would now carry free and subscription services in most major markets around the globe. Beyond gaming and Netflix and Hulu, which have been part of Xbox for some time, the connected gaming console will now carry channels like ESPN, HBO, Bravo, Syfy, BBC and services like Comcast Xfinity, Verizon FIOS and TT&T and previously Web-based content like Google's YouTube.
For all of the talk of potentially disruptive Over-the-Top TV services, this is probably the most significant move we've seen since Netflix and Amazon launched their streaming services. Am I being a bit extreme? I don't think so, and here are my reasons why:
Xbox already proven platform for TV viewing. Connected Xboxes today are already used for TV viewing on average of one hour per day. That dwarfs the average Americans Web video viewing by by a factor of 10. More great content on that platform will only drive that number, and ratio, higher.
Beginning of the end of cable company proprietary set-top boxes. It is significant that several of the largest multichannel video distributors have signed up on the Xbox deal. I'm sure many of them would like to be out of the consumer hardware business. Just wait until we see large volumes of smart, connected TVs. They will become like Xbox too.
Could herald a la carte channel purchasing. With ESPN and HBO doing deals here, how long can it be before other, must-have networks, offer their channels on a stand-alone basis - AMC and "Mad Men," anyone?
Fast path to major ad revenue steam for Microsoft. Steve Ballmer has made it clear for years he aspires to eventually drive 25% of the company's revenue from advertising. Online is not likely to satisfy that goal. TV and it's big dollars just might. Don't underestimate what a company like MSFT might do to finally achieve that big audacious goal.
PRINT
COMMENT
SUBSCRIBE
RSSSaturday, October 1, 2011
How To Prosper As a Product Manager - Redefining and Strengthening the Product Manager’s Role
The title “product manager” is the most commonly held marketing position. Product managers are essential to a company’s efforts, yet the position is fraught with frustration. Often, product managers are disappointed to discover that tactical coordination requires so many of their working hours. Why does the strategy-oriented job they thought they had accepted so often become lost among the rest of the position’s demands?
Most literature in the field has focused on factors affecting a new product’s success or failure, including the quality of market research or a product’s superiority. Mohanbir S. Sawhney, a clinical professor of marketing at the Kellogg School of Management, and Rajesh K. Tyagi, an assistant professor at HEC Montreal, believe that too little research has looked at the role of the product manager and the relevant processes and organizational structures. They set out to explore the circumstances that affect, define, and ultimately determine a product manager’s effectiveness. In essence, what makes a successful product manger? The answer is simpler than you may think.
Product Managers at Work
Imagine the product manager as an orchestra conductor, and the product as the symphony being played, Sawhney suggests. “The conductor doesn’t play an instrument or sing, but needs to coordinate all the players,” he notes.The product manager doesn’t have a script to follow, but all the functions need to come together to make the product succeed.
However, he continues, the conductor is following a score. “The product manager doesn’t have a script to follow, but all the functions need to come together to make the product succeed. This means that market research has to provide the right customer insights, engineering has to build the right product, the supply chain must get the product to the customer, and the salespeople must be effective in selling.”
Product managers supervise the everyday marketing of a company’s products, both current and those in the pipeline. Despite the job’s pivotal nature, its roles and responsibilities can be very unclear—job descriptions are often poorly defined, and many product managers lack the authority to carry out their responsibilities effectively.
The position’s significance varies among industries, and is far more common in technology than in consumer goods. “Proctor and Gamble has brand managers, not product managers. Consumer products are not all that complex, so it’s all about the brand,” Sawhney explains. Technology companies such as Apple and Microsoft have more complicated, expensive products and therefore a stronger need for product management.
Identifying Impediments
Sawhney and Tyagi developed a detailed, four-part questionnaire after lengthy interviews with more than twenty experienced product managers. Of the 198 survey respondents, more than 40 percent worked in business-to-business technology and nearly 23 percent in industrial products. The product managers averaged 7.4 years in the position and 42.3 percent of them held advanced degrees.One of Sawhney and Tyagi’s hypotheses was that organizational barriers, short-term tactical focuses, and a lack of formal training impede communication and weaken a product manager’s performance. Another theorized that organizational silos and barriers affect roles, responsibilities, knowledge, and competencies, all of which can determine product management performance. They also anticipated that customer knowledge and strategic thinking were key competencies for the role.
In most cases, product managers have little influence on corporate branding, channel selection, or advertising. Rather, they have greater input in defining product specifications, launching the product, and positioning the product. Sawhney and Tyagi found that the marketing department is often brought into the product management process once the developed product is ready to enter the marketplace.
In Sawhney and Tyagi’s survey, product managers reported they felt that the sales function, followed by engineering, wields the most power in an organization. They considered corporate marketing the least powerful function, with comparatively little direct authority over budget and ownership.
More authority would increase a product manager’s effectiveness, Sawhney says. Usually, “the product manager must master the art of influence without authority—and that’s not easy,” Sawhney observes. The study identified the position’s two most important skills as product knowledge and customer knowledge.
Another critical factor—a product manager’s interfaces—is often managed poorly. “It’s hard for the product manager to get to either the people or the needed information, because so many interfaces are required, with sales, R&D, operations, advertising, finance, the supply chain, and executive management,” says Sawhney. “A good product manager should spend 20 to 25 percent of his or her time with the customer. We found they spend as little as 14 percent with customers, and as much as 38 percent on administration and follow-up.” Survey respondents would like to spend more than one-third of their time on planning and strategy, but can devote only about 25 percent to those activities.
Sawhney and Tyagi identified firms’ organizational structure as the biggest determinant separating those that perform high in product management from lower performers. “There’s no shortcut if you really want to fix the product management function. Where that does happen, leadership has to set the tone,” Sawhney reports. “The corporate culture has to empower the product manager. Jeff Raikes, who ran the Microsoft Office business for many years, was a product manager. So the product manager role is well-respected in Office business development [there].”
Empowering the Position
One study participant at Oracle said salespeople rarely take product managers on sales calls, fearing they will get in the way. When an Oracle product manager researched how their new product could compete against IBM’s, a salesperson who heard about the information invited him on what turned into a successful sales call. Word quickly spread that the product manager was the one to contact when competing with IBM. Soon he was getting frequent invitations to go on sales calls. “It’s all about what you know,” explains Sawhney. “If you have the credibility that comes with the knowledge, you’ll get a seat at the table—but you have to contribute something of value.”“A product manager needs to gain power through expertise,” Sawhney asserts. “If you can make sales or engineering feel that you are the ‘go-to’ person for your product, you can become more influential.”
Product managers should not “be thrown into deep water” to learn on the job, Sawhney says. Instead, he recommends formal training as they enter the organization and as they begin climbing the corporate ladder there. Strengthening the position’s power can significantly contribute to improving product management outcomes.
The quality of the marketing process impacts a product manager’s performance. Sawhney and Tyagi suggest that managers of consumer products be directly involved in creating the marketing requirements. With industrial or technology products, marketing and engineering should jointly define the requirements. “High-performance firms … have a clearly-defined process for product launch, escalations, and need identification,” they conclude.
Making the product manager responsible for more of the total product functions can mitigate interface difficulties. Sawhney recommends “creating mechanisms for better communication across functions, or restructuring the organization” to remedy interface problems.
A realistic starting point for the employer is to define and sharpen the product manager’s job description. Sawhney has been consulting with Microsoft for some time on improving the product management function. “Microsoft is in the middle of a new program, Role Clarity, which goes across marketing functions, including product management. The impetus is coming from the top, acknowledging the importance of [defining] roles and responsibilities in product management.”
The study’s most important finding, says Sawhney, is that product managers encounter too many barriers, organizational silos, and vagueness about what they can or should be doing. “Once you reduce the ambiguity around things like their deliverables or specific authority, performance improves. The clearer the roles and responsibilities, the more successful the product manager.”
Thursday, September 29, 2011
Minimum Viable Personality
Today we have a special guest post. There have been a few guest posts here at AVC. Maybe a half dozen in total. One of my favorites was this one by JLM during the financial crisis of 2008/2009. But this one today may top that gem.
It's from our favorite Giant Robot Dinosaur and it's about Minimal Viable Personality, something I have referred to as "voice" in pior posts. The Grimster is so right that this is critical to building a successful product.
One final note. If you want to tweet out one or more of the many awesome quotes in here, please add the hashtag #grimlockquotes. I'd like to watch them come in. Because you know they will.
------------
MINIMUM VIABLE PERSONALITY
MOST IMPORTANT STEP FOR BUILD PRODUCT IS BUILD PRODUCT.
SECOND MOST IMPORTANT IS BUILD PERSONALITY FOR PRODUCT.
NO HAVE PERSONALITY? PRODUCT BORING, NO ONE WANT.
PERSONALITY BETTER THAN MARKETING
WHEN CHOOSE PRODUCT, HUMANS ONLY CARE ABOUT DOES WORK, AND IS INTERESTING.
WORLD ALREADY FULL OF THINGS DO WORK. MOST BORING.
PERSONALITY = INTERESTING. INTERESTING = CARE. CARE = TALK.
EVERYONE CARE AND TALK ABOUT PRODUCT? YOU WIN.
SELL TO FRIENDS, NOT STRANGERS
PERSONALITY MAKE PRODUCT FRIEND. YOU HELP FRIEND. YOU FORGIVE WHEN FRIEND NOT PERFECT. YOU WANT FRIEND WIN.
BORING STRANGER?… YOU NOT.
PERSONALITY IS API FOR LOYALTY. NO ONE CARE WHICH BORING STRANGER IS NEXT. BUT ALWAYS WANT FRIEND NEXT.
PERSONALITY MAKE MEANING
CAN PET ROCK. PET DOG BETTER. PET DOG HAVE MEANING.
BORING PRODUCT IS ROCK. NO HAVE MEANING. INTERACT WITH PERSONALITY DIFFERENT. HAVE MEANING.
INTERESTING PRODUCT THAT GIVE FRIENDS MEANING = MOST WIN OF ALL.
HOW NOT BE BORING
HAVE PERSONALITY EASY. ANSWER THREE QUESTIONS:
1. HOW YOU CHANGE CUSTOMER'S LIFE?
2. WHAT YOU STAND FOR?
3. WHO OR WHAT YOU HATE?
NOW HAVE MISSION, VALUES, ENEMY. THAT ENOUGH FOR MINIMUM VIABLE PERSONALITY.
KEEP IN BRAIN WHEN WRITE, TALK, BLOG, TWEET. ITERATE. IMPROVE WHAT WORK. DELETE WHAT NOT. PERSONALITY GROW.
NO BE CHICKEN
CHICKEN LIVE IN CAGE. NO CAN HAVE PERSONALITY INSIDE CAGE.
LAST STEP IS SMASH CAGE, LIGHT BARN ON FIRE.
DO THAT, YOU WIN.
Wednesday, September 28, 2011
API design for humans
One of the things about working with data at 37signals is that I end up interacting with a lot of different APIs—I’ve used at least ten third-party APIs in the last few months, as well as all of our public APIs and a variety of internal interfaces. I’ve used wrappers in a couple different languages, and written a few of my own. It’s fair to say I’ve developed some strong opinions about API design and documentation from a data consumer’s perspective.
From my experience, there are a few things that really end up mattering from an API usability perspective (I’ll leave arguments about what is truly REST, or whether XML or JSON is actually better technically to someone else).
Tell me more: documentation is king
I have some preferences for actual API design (see below), but I will completely trade them for clear documentation. Clear documentation includes:
- Examples that show the full request. This can be a full example using
curllike we provide in our API documentation, or just a clear statement of the request like Campaign Monitor does for each of their methods.
- Examples that show what the expected response is. One of the most frustrating things when reading API documentation is not knowing what I’m going to get back when I utilize the API—showing mock data goes along way towards this. Really good API documentation like this would let you write an entire wrapper without ever making a single request to the API. Campaign Monitor and MailChimp both have good, but very different takes on this.
- A listing of error codes, what they mean, and what the most common cause of receiving them is. I’m generally not the biggest fan of the Adwords API in many ways, but they are a great example of exhaustively documenting every single response code they return.
- A searchable HTML interface. Whether it’s visually appealing doesn’t really matter much, and Google indexing it is plenty of search. What doesn’t work for me is when the API documentation is in PDF, or I have to authenticate to get access to it.
- Communication of versioning and deprecation schedules. There’s some debate about whether versioning is better than gradual evolution, but regardless, anytime you’re changing something in a way that might break someone’s existing code, fair warning is required, and it should be on your documentation site. Sometimes you have to make a change for security reasons that don’t allow much advance notice, but wherever possible, providing a couple of weeks notice goes a long way. The Github API clearly shows what will be removed when and shows the differences between versions clearly.
Let me in: all about authentication
Most APIs either use OAuth/OAuth2, user/password or API token via HTTP basic or digest authorization, or a special parameter included in each request. These all have advantages and disadvantages:
- OAuth and the still developing OAuth2 are becoming the defacto standard for any API that primarily expects the API consumer to be a third-party application. It’s secure, relatively consumer-friendly, and relatively easy to use. The downsides: implementations vary slightly across service providers (I often hear that “the documentation is the implementation”), and it’s a lot of overhead for something where you just want a single piece of data.
- User/password or special API token via HTTP basic or digest authorization is fast, doesn’t require anything more than
curl, and you can even make some request from a browser. The downside here is that it’s not especially “friendly” to ask an end-user to go find an API token.
- User/password or API token as a URL parameter fortunately isn’t very common. It’s more confusing than basic authentication, has all of the same downsides, and no real benefit.
There’s clearly a tradeoff here—OAuth is great for delegating authorization for a third-party, but API tokens are better for quick access to your own data. My preference is for an API to offer multiple methods of authentication so you can choose the best method for what you’re trying to do.
Underlying design: REST or something like it
There’s a formal definition of REST, and endless debates have erupted over whether a given API is truly RESTful or not. As a consumer of APIs, I don’t really care whether it’s technically RESTful, but there are a few “RESTlike” attributes that do matter:
- Not SOAP. I know there are legitimate reasons to have a SOAP API, and I can imagine that translating a massive API from a legacy SOAP to REST interface is quite difficult, but it’s incredibly difficult to consume SOAP if you have to develop a client library from scratch or do anything non-standard.
- Use HTTP verbs to mean something. Any API consumer is capable of sending
GET,POST,PUT, andDELETEverbs, and they greatly enhance the clarity of what a given request does. It’s terrifying to use an API where aGETrequest can change the underlying data.
- Sensible resource names. Having sensible resource names/paths (e.g.,
/posts/23instead of/api?type=posts&id=23) improves the clarity of what a given request does. Using URL parameters is fantastic for filtering, but if everything is based on a single API endpoint and tons of parameters, the mental model required to use it gets too complex very quickly. I really like the way Assistly’s API has implemented resource paths and uses HTTP verbs.
- XML and JSON. I like JSON. Some people like XML. Unless the costs of offering both are staggering, offer both. Ideally, you’ll let me switch between just by changing an extension from
.xmlto.json.
- Use abstraction where it’s helpful. Your API implementation does not have to mimic your underlying application architecture. For example, the Adwords API has 25 distinct “services”, each of which seem like one module of the underlying implementation. This is logical if you implemented it, but that doesn’t make it particularly friendly to use—if you wanted to retrieve your click through rate for each ad you’re running, you’d end up making (literally) dozens of distinct requests. On the other hand, the Google Analytics data export API lets you define reports so that you rarely have to make more than one request, but you’re still only fetching what you need. If you think there’s some common action that people will go to the API for, you should make that action easy, even if it means compromising on ideology.
These are my preferences, and there are no hard and fast rules of API design. Regardless of whether you apply any of these principles in your next API, I would absolutely encourage you to look at your API from the standpoint of a consumer. Maybe try building something small using your own API – it can be an eye opening experience.
