Sales engineer versus product manager

As my role as the API Product Manager and Owner for Ticketmaster has grown - a direct result of the increase in API adoption, growing user base and product feature expansion - it is finally time to bring in some help.

We're hiring both an API Sales Engineer (or Integration Engineer or API Analyst) as well as an Affiliate API Product Manager. Someone I work with recently asked me what the difference was between the two roles - Product Manager and Sales Engineer. Because I play both roles today for the Ticketmaster API, maybe the differences aren't so clear.

It often isn't clear to others (especially non-techies) what a Product Manager does (let alone an API Product Manager) and what their value to a business this. It especially isn't easy to understand what a Sales Engineer does, until it is explained to you.

Read more: Sales engineer versus product manager

Software engineering use case template

This post is the first in a series of posts (hopefully) aimed at helping those in an Internet product-related position - product manager, project manager, marketing manager, usability designer, interaction designer, qa tester, etc - do their daily jobs better. I'll be adding templates, advice, strategies and other gems on information that I've absorbed over my 12 years creating and managing online products to this blog.

The first challenge I'm hoping to help people address is this: what is an alternative way to easily and effectively communicate my requirements or needs around a certain idea I have? How can I more effectively convey to an engineer what the feature should do? My answer is the Use Case. 

Purpose For a Use Case

Use cases provide an excellent method of describing what a product, system, feature, etc is supposed to do. It is an effective alternative to the more traditional methods of documenting functional requirements and business rules and helps to provide software engineers with a clearer picture as to what the desired objective of a feature is.

Every good use case should try to convey the following:

  • Goal - Have a goal in mind; a stated objective that should be met if the steps of the use case are successfully completed.
  • Actors - Identify the users, systems and other actors involved in the use case.
  • Preconditions - State the conditions that must be met for use case to start and end successfully.
  • Related Use Cases - Reference other use cases that either use or follow the use case.
  • Steps - List an ordered set of interactions the actors must perform to achieve the goal.
  • Alternative Steps - List any variations in the steps of the use case.
  • Business Rules - List the non-functional requirements or business rules that must be respected when achieving the desired result.
  • Business Requirements (optional) - You may decide to enumerate specific business requirements in the use case also.

Read more: Software engineering use case template

The Commute

So, I started my new job as Senior Product Manager Ad Systems at FOX Interactive Media this week. So far, the commute home hasn't been all that bad. However, the commute to work has been brutal so far. Today, it took me 1 hour and 40 minutes to get to work. Most of that time was spent in the parking lot between Roscoe and Sunset that is the 405. I'm going to try different routes to see what works best. However, suffice it to say that going to Santa Monica via the 118 and 405 in the AM is not the way to go. This is the route that I'm gonna try tomorrow... LA Ave to Box Canyon to Valley Circle to Muholland to Topanga Canyon to PCH (Hgwy 1) to the 10 exit 20th St then Broadway. Check out the map...


Read more: The Commute


Follow Adam