Sunday, November 7, 2010

Quality Counts

Quality matters much more in a SaaS offering than with an on-premise offering.

QA managers may disagree with me -- after all, it's their job to get quality right regardless of the delivery model.  But in my experience, SaaS gives a vendor far less room for sloppy quality than with an on-premise solution.  Some of this is really a question of velocity.  With most SaaS solutions, an upgrade is done for all customers at once or for large blocks of customers in server "pods", which makes it a fast and efficient model for putting new capabilities into customer hands.  Unfortunately, it also means you're putting bugs into your customers' hands quickly and efficiently!

In an on-premise model, when a new release is shipped, there's generally a nice, gradual roll-out, as customers take the upgrade on their own schedule.  If 10% of a customer base adopts a new release in the first month or two, that's not a bad take-up rate at all, and problems will tend to start trickling in, not gushing.  That gradual pace often gives the vendor time to fix reported problems before too many customers are impacted.  And that's often why customers choose to wait, of course -- give it a couple of months, and someone else will suffer through the release's teething pains.

But with a SaaS model, the entire installed base may go to bed on one release, and wake up to another.  If there are quality problems, there are no gradual roll-outs -- no early adopters to find the problems on behalf of the rest of the pack.  The effects of poor quality will be multiplied, accordingly -- from Support, to Engineering, to Account management to the Executive team.  And remember, delighting customers and securing renewals are the name of the game with SaaS.  Poor quality, in this case, can be terminal.

There are many ways to keep quality problems at bay.  But I think the most important is cultural.  QA is often under-resourced relative to Development, and it's not uncommon for developers look down their noses at their QA counterparts, instead of looking to them for partnership.  An organization serious about stamping out quality problems could do worse than to look for and eliminate these two causes (I'm betting they'll be found more often than not).

As Product Managers, we need to champion that cause, and also acknowledge our own contribution to quality problems.  It's tempting to ask for one more feature, change or bug fix late in the game.  It's easy to look at our backlog of enhancement requests and conclude that we can't live without way more than can reasonably be done in a high quality manner.  We need to remember that the software has to work, and work well.  There are no more important requirements, and shame on us if we put the business at risk for something lesser.

There's a good case in here for agile development approaches, as well -- more on that another time.

All for now,


Tuesday, October 26, 2010

Who Owns Renewals?

For a company with a traditional on-premise license/maintenance pricing model contemplating a shift to a subscription business, the revenue model changes in several important ways.  Rather than getting a big license fee up front and a small annuity, the initial value of the deal drops, the cost of servicing the account goes up, and the annuity increases.  Making money here depends on delighting customers and getting them to renew multiple times.  And once you've got a base of happy customers, the bulk of your revenue will come not from new sales, but rather renewals.  I've talked about this already, I know, but it's a huge conceptual shift for a company used to living on new business.

So how to make sure customers renew?  It really starts with ownership and accountability -- ownership of and accountability for revenue.  Who owns revenue?  Typically that's Sales.
The shift in the revenue model puts the VP of Sales in an interesting position.  A successful SaaS/subscription business will eventually value farmers more than hunter/gatherers, because successful farmers will represent the main source of revenue.  Most of the VPs of Sales I've ever known were principally hunters who were used to building teams of hunters.

But if they want to keep their stature in the company as the executive responsible for revenue, these folks can't just be the VP of Sales -- they have to be the VP of Revenue -- of Sales and Renewals.  They need to think just as hard about how to be absolutely sure that customers are delighted and will renew, as they do about how to win that next deal.  Or even harder.  And they need to be prepared to organize their department accordingly, with rock-solid account management teams whose job it is to ensure that the revenue keeps flowing from happy customers year-over-year.

This is a pretty big change in role, and it's not one that every VP of Sales will immediately understand, or be well-suited to.  And if they're not up to it, the responsibility may better fit with a VP of Services or client care or something.  The big problem I've seen with this approach is that the potential for conflict is greater when hunters and farmers report into two different departments, let alone two differnent teams.  Comp plans can work out some of the conflicts, but there's no substitute for having teams that can work well and closely together.

Where have you seen this responsibility land, and how did it work out in your case?  What were the challenges and advantages of the approach?

Regardless of where this lands, ownership and accountability are crucial to success.  As PM, you're at the hub of making sure the organization is ready to make your product financially successful, and it's important to drive this issue to conclusion as you're preparing your GTM plan for your SaaS/Subscription product.  If you're not confident in the ownership, the incentives, the staffing plan or the accountability, neither should you feel confident in the long-term financial prospects of your product.  Talk to your CFO, the VPs of Sales and Services -- the CEO if you have to.  Whatever it takes -- get this right.

All for now,


Thursday, October 21, 2010

Feature Boy and Demo Girl

Maybe 10 years ago I attended the Pragmatic Marketing course along with a Marketing team I was then part of.  I enjoyed it and found it worthwhile, but mostly in the context of the whole department getting on the same page about what our roles would be in launching products.  Beyond that, it was a good reminder of best practices and there were a bunch of great tips in there.

One of the cautions Steve Johnson (our inimitable instructor) gave us was to avoid becoming Demo Boy or Demo Girl -- to remember to keep our eye on the market, and not to let the Sales team bleed us dry with building and delivering demos.  Good advice, a decade later.  Since then, I've either heard or read or made up a corollary to Steve's Demo Boy/Girl caution -- that is, to also avoid becoming Feature Boy or Feature Girl.

There's a balance in both of these cautions that needs to be maintained.  Being invited to give demos gives you an audience to learn from -- time with customers and executives who can help you with your product, your market, and your career.  And likewise, learning the in's and out's of your product, either through giving demos or reviewing features closely with developers and designers gives you great insight into how well or poorly it'll actually satisfy the market needs you wanted to address.

The trouble is, if you're great at giving demos or shaping features, the people that need a demo or help with a feature will do everything they can to use your talent to their advantage, leaving you less time to do other important work.  Deflecting these requests or finding ways to scale them is a classic PM challenge, and I'd love to see comments back with your personal tricks -- I'm sure we'd all benefit from them!

Whatever your approach, remember that your job is to be the custodian of a product -- the custodian of that business -- not to be the savior of a feature or a deal.  It's the rep's job to close the deal, and the engineering team's job to deliver well-designed capabilities that work as intended.  They need to do their jobs, and you need to do yours.  Keep your eye on the problems your market needs solved, and focus on leading the organization to solving them.

All for now,


Tuesday, October 19, 2010

If you don't ask...

Knowing what anyone else is thinking or feeling is a tricky business, so how do you really know that your SaaS customers are delighted and likely to renew?

The SaaS model offers great potential for seeing how/how much customers are using your system.  As PM's, we need to think about what visibility we need to know customers are happy, and find a way to get that data.  Instrumenting the product to capture it needs to be built into the requirements early on, or you'll be constantly trying to catch up with your needsas they evolve.  We also need tools to view and analyze the data, and finally to make time to actually look at it, interpret it and use it in improving our systems.

There are some obvious examples of quantitative metrics to think about:
  • The number of unique users who are logging in, relative to the number of subscribers
  • The amount of use they're giving the system (how often do they come in, and how long are they using it)
  • The type of work they're doing with the system
The specific metrics are going to vary from one solution to another, and if you know your business it won't be hard to figure out what you need to know.  In a word processing application, the volume of documents created may be really important, for example, but with a project planning tool, the number and frequency of users posting project updates may be what matters.  Understanding trends is important, too.  For example, is usage rising or falling?  And is rising or falling normal, say, for the period of the business cycle, or an indicator of something going wrong?

Insight into other parts of your broader solution may be important, too.  For example:
  • The usage of education materials within a customer's user base
  • Support statistics for a customer (how many incidents, what types of incidents, how quickly they were resolved, etc)
  • The number and types of suggestions for enhancements that have come from the customer
This second set of metrics may well be produced and stored by different systems managed by various parts of your organization.  Pulling them together into a single view of the customer may be difficult, and this is where having an IT/Operations team truly focused on the unique needs of a SaaS business can make a big difference.  Getting a solid picture of your customers' experience with your entire solution is crucial, and can help not just PM's with decision making, but the customer care teams as well.  If they're not already concerned with this insight, consider it your responsibility to get them concerned!

Stats are useful and important, but it's just as important to ask customers how they're doing, and let them tell you what's really on their mind.  Customer calls and visits are indispensable opportunities to do this as PM, but this task ought to be operationalized by the customer care teams as well.  Consider polling customers regularly with a brief survey -- for example, after each support inquiry (up to once per month) or proactively on a quarterly basis, if the customer hasn't initiated outreach themselves.  So armed, your customer care teams can address satisfaction issues before they become a risk factor for renewals.

Knowing where your customers stand is crucial to keeping them happy.  What are you looking at to gauge customer satisfaction?  And how are you using that data across your organization?  I'd appreciate your insights!

All for now,


Sunday, October 17, 2010

Delighting Customers

I'd been a PM for 10 years or so before I first heard the phrase "delight our customers".  It struck me as an odd turn of phrase, honestly, mostly because I don't often hear the word delight or its variants outside the context of polite social discourse.  But the idea of truly delighting customers carries with it a lot of powerful implications, and the expression itself is powerful in part because the word delight gets people's attention.  It's a great way of planting a stake in the ground as to what's truly expected and required, particularly if I find myself in a room full of folks who've grown weary of trying to cover too many bases with too little resources.

And make no mistake -- in a SaaS business in particular, everything hangs on delighting customers.  The subscription revenue model makes it imperative to delight them and secure their renewals (and expansion) year-in and year-out, and if your customers can't see their way to delight, their renewals (and your business) are at risk.  To make things even more interesting, the SaaS delivery model raises the stakes for delighting customers far beyond what you see in an on-premise model.

The chief driver of this raising of stakes is the way in which customers interact vendors and their solutions.  In a SaaS model, the vendor doesn't just own the solution -- they "own" everything.  Everything about the user's experience from the point their PC touches the Internet sits squarely in the lap of the vendor, and in some cases.  Opportunities to distribute blame for a shabby experience are few and far between, and even if there were, it's the vendor who will ultimately suffer the most from unhappy customers -- the vendor needs renewals to make the subscription business model work.

Fortunately, the connected usage model gives us some great opportunities to stay in touch with our customers, and understand how we're doing at keeping them happy.  Because the users are connected, the potential exists to gather a great deal of insight into how they are or aren't using the system.  That can start with something as basic as tracking when users get in and how long they stay, but by instrumenting the product to track user activity within the product UI, much greater insight can be gained -- actionable insight.  If you're trying to figure out where to enhance your solution, wouldn't you love to know which features users actually use the most?  The least?  Wouldn't it be great to see where users get confused and abandon things they start?  Anyone would, of course.

Other than getting genuine visibility into how the system is being used, there's also a fantastic opportunity in a SaaS model to engage with users.  Because they're connected, you can ask them in real time what they think:  How do they like the system?  What do they think of this new feature?  How are the colors working for them?  Was this help useful?  What do they need more of?  Less of?  And that dialog doesn't just give you the ability to ask them questions, it offers the potential (and carries the obligation) to tell them what you're up to:  What's coming and when?  How will they be affected by a change, and how will they not?  A big part of delighting customers is avoiding unpleasantly surprising them.

For organizations used to an arms-reach relationship with customers, there's a lot of new ground, here,  But the core of a successful business remains the same as it has for centuries -- you need delighted customers.  As you think about your own organization, I'd love to hear examples of the energy you've seen in this direction.  Thanks, as always, for sharing.

All for now,


Wednesday, October 13, 2010

Supporting a Subscription-based Business Model

One of the most significant changes for many companies moving from on-premise to SaaS is a shift in the pricing and licensing model.  It's critical for product managers to understand the differences -- to truly incorporate these distinctions into their decision-making framework, or literally risk failure.

Typical on-premise fees are structured in a license+maintenance model, where the cost to acquire the software is high, and then there's a smaller fee that recurs annually to cover the cost of upgrades and support.  Because SaaS software solutions are a service, the fees are generally structured around an annual contract where each year the customer pays the same amount, provided that their usage is consistent.  Because the fee recurs, it is generally smaller than the up-front license fee in an on-premise model, but larger than the maintenance fees.

So what's the impact of this on PM's?  Don't we still have to satisfy the needs of the market?  Don't we need to keep our customers happy either way?  Yes, of course we do.  But it's still very important to have a crystal clear understanding of how revenue is flowing into our companies, as well as the drivers and risks associated with that revenue.  How else can we make the best decisions as custodians of the business?

As PM you should be able to build a financial model for your business, to get a feel for how money will flow in under different assumption sets, and how you'll spend the money -- just a simple P&L should give you the insight you need.  If you can't do this, you should learn how, or even just ask a Finance person to sit you down over lunch one day and help you build something that you can run with.  I suspect what you'll find is this:  in an on-premise model, new business is the life-blood of your company, but in a SaaS model, renewals quickly become the life-blood, after a few years of building a book of business.  They're both important in both models, but their relative weight is decidedly different.

Think about that -- renewals will become the life-blood, not new sales.  How does that affect how you view your investment choices as PM?  How does that impact the calculus you make when you're processing feedback from your various internal and external stakeholders?  In a SaaS/subscription world, your Sales team is still going to insist you go after things that will help them close new business -- that's how they tend to get paid, after all.  But when you model the impact of that spend, vs. fixing issues that are dragging down satisfaction levels and putting pressure on renewal rates, you're likely to find one-off deals to be of little importance.

This isn't just a shift for you as the PM, it's a shift that in a very real way re-levels the importance of different functions within the organization.  Where your hunters have previously been the main contributor of revenue, other teams (service, support, and account management functions) may now be more important.  The organizational dynamics of such a change are not trivial, and as PM's we'll be right in the thick of it, with the mission of getting everyone at the table to understand the flow of the money.  And as I said, the stakes are high -- without high levels of satisfaction and outstanding renewal rates, the SaaS/subscripton model probably isn't sustainable.  Get it right or go home.

This is hard stuff, but it's a big part of why this is the best job ever.  If you're reading this, and have made this transition, you're undoubtedly familiar with this work.  What else have you seen?  Do you have any stories to share?  Thanks, as always, for your thoughts.

All for now,


Thursday, October 7, 2010

Comparing SaaS to On-premise

If a product manager is the custodian of a business, and if the core responsibility of the product manager is to make sure that business is successful, it's incumbent upon the product manager to understand what the business needs to be successful.  I think that's a fair position and a fair expectation to levy on the PM team.

But for a PM used to working in an on-premise model, delivering software as a service will alter large chunks of their familiar playing field. Some of these changes will stem from fundamental shifts in the business model, others from shifts in responsibilities towards the vendor, and still others from changes in customer expectations based on their experiences with other solutions. Product managers need to understand these shifts, both in general terms and in terms that are specific to their business (market/industry/company/solution).

So how are things different in SaaS?  Let me tee up some major topics, and I'll drill into them in more detail later.  In many cases there's a lot to go into, and far more than can be covered in one post:

Business model:  If I can generalize for a moment, it's common for on-premise solutions to follow a license/maintenance pricing model, and for SaaS solutions to follow a subscription model.  Regardless of how software is delivered, these two pricing models create very different revenue streams, and these very different revenue streams will create very different lenses with which your organization will view customers and their satisfaction.  This one isn't a SaaS issue per se, it's a pricing model issue, but its impact is huge and PM needs a deep understanding of the differences.

Operations:  With a SaaS model, the vendor is essentially assuming all responsibility for delivering their solution to the client.  The customer's IT organization doesn't own those "five nines" of up-time -- the vendor does.  So there is no room to be anything but flawless in operational execution.  If you are going SaaS, you will need a stellar head of SaaS Operations, and they will need a seat at the Product table equal to that of the heads of Development, Quality and Product Management.

Risk:  When an on-premise upgrade is released, the risk associated with bugs is relatively low.  Even if an egregious bug is found in the field, the generally slow adoption of new releases will ensure that there is plenty of time to address the issue before a large set of users is affected.  In a SaaS model, new releases will more commonly be deployed to all customers at once, or to "pods" of many customers on a specific schedule.  Bugs in the code, or problems in the configuration of the software or infrastructure will affect many users across many customers in short order.

Requirements:  With SaaS comes the opportunity and responsibility to rethink many aspects of your customer experiences around the software, and alignment around which of these you will pursue and when is important early on.  In addition, there will be entirely new drivers of requirements stemming from your SaaS Operations team, and their needs.  And changes in the business model will drive still other requirements aimed at understanding usage and satisfaction.  There's just so much to think about on this score -- nice, rich topic on its own!

Enginering:  Changes in requirements and deep participation from Operations will alter what Development needs to create, and the elevated risk profile may well require greater consideration of and respect for the quality organization, depending on the discipline and culture in place.  SaaS teams generally can't afford for the Quality team to be a poor cousin to Development, and the true "rock star" coders should be the ones who deliver quality, not just innovation.  There's a really good case to be made that agile development and SaaS should go hand-in-hand, as well. I can certainly chime in on that, but I don't consider myself an expert in development methodologies, and will need to disclaim what I say, there, when the time comes.

Marketing:  SaaS can change the nature of the conversations technology companies have with prospects.  Without having to convince IT our solutions are fit for their infrastructure, we as marketers can relax about how clever our engineers were in building the things, and focus on discussing the business value of our offerings with buyers.  There is still a need to engage with IT, sure.  But it's a different and toned-down conversation in many cases, and rather than filling our websites and data sheets with boasts about our technology, we can focus on the benefits prospective customers can expect if they subscribe.  And with SaaS, marketers also get new opportunities, channels and obligations to communicate with customers, and need to be ready to capitalize on and satisfy thess.

Selling:  There is an opportunity with SaaS to solve problems in such a way that using a sales force engaged in a typical enterprise sale will prove unnecessary.  But whether that opportunity fits with your problems, solutions and organization is another question, and regardless of the answer, you need clear alignment internally on this point.  In fact, a vision of how you want to bring your SaaS solution to market ought to be at the start of the project.

Implementation:  As with choosing an approach to selling, you ought to establish assumptions about how your system will be provisioned and implemented very early on.  Whether you want customers to be able to self-service on one or both counts, or whether you prefer to have a services engagement of some kind will drive a big set of requirements and an even larger set of design decisions along the way.  And if the goal is to ultimately move to a self-implementing model, it can be really difficult to get there if the system wasn't envisioned with that goal in mind -- it's a lot easier to complexify something that's simple than simplify something that's complex.

Education:  I'm convinced that the right thing to do for any piece of software is to hire great designers and make the user experience so good that documentation and training become largely unnecessary.  But where it is necessary, SaaS introduces options for innovative ways of helping customers that aren't practical with other delivery models: An ongoing library of video tutorials, for example, delivered based on customer usage and feedback, with links from the appropriate screens added as the content is developed.  The possibilities are really endless, as are the sources for inspiration out there (the b-to-b and b-to-c SaaS solutions we all encounter in our lives).

Support:  Online support models have been around for a very long time, but in a SaaS solution, your customer is by default already connected to your company and its resources, every time they log into the product.  That opens up the possibility for embedding support resources and experiences into the application, rather than requiring users to stop what they're doing to go off to some other place to get help.  The definition of "support" is also open to interpretation, with community, eductional, online chat, Skype and other options at your fingertips.

These are really just a few of the areas in which product management needs to be ready to provide leadership to the rest of the organization.  As I start to peel the onion on these and other subjects, I'd love to hear other thoughts and ideas, as well.  Thanks for reading and sharing, as always.

All for now,


Saturday, October 2, 2010

SaaS is Different

One of the best experiences of my career came at my last company, where I helped shepherd the change from on-premise deliver to SaaS.

It wasn't my idea to move to SaaS -- that was my boss' idea, and it really stemmed from a position of poor leverage.  As a small company, we didn't have enough horsepower to tell the IT organizations of large companies which platforms they needed to support in order to have the honor of running our solutions.  Rather, they expected us to snap-to, and support whatever DB, application and web servers they had standardized on.  And as a little company, we didn't have a prayer of supporting all of the platforms that we knew were out there.  Shifting to SaaS was very much a defensive move, from that perspective.

Once the decison was made, though, it became clear that a lot would have to change across the organization.  It's the breadth and depth of that change that made the experience so fantastic.  And it was the uniquely central position of the PM role that allowed me to play the role of shepherd.

Make no mistake -- running a SaaS business is different, and the differences are pervasive, from the business model through the customer care requirements.  For an organization contemplating the shift, it is incumbent upon every function to ask what they must do differently than they did before to succeed in this new model.  And it's incumbent upon the PM to provide the vision for each function to draw from in answering that question.  The PM is the custodian of a business, and must lead the organization in the direction that will spell success for that business.

I'll start drilling into this premise next time.

All for now,


Wednesday, September 29, 2010

What is product management, anyway?

For me, one of the most interesting parts of the product management role in software is that it can be so different from one company to another.  It's highly subject to variation from place to place, based on a company's executive team, its culture, the kinds of products it makes, and the other roles on-staff.

When talking about product management, I used to frame the job in terms of a triangle, whose points denoted the three most common responsibilities of the PM role -- Marketing work (principally, understanding the market and generating the core of the solution messaging), Product work (articulating the market needs and defining the solution requirements), and Project work (some form of cross-functional go-to-market/readiness planning).  Something like this:

I'd often scribble something like this (including pertinent examples of the kind of tasks I've included here) on a white board when bringing new PM's up to speed, talking to new engineers, or even in interviews.  My point was that the product management role for any given organization could be defined as a shape (the blue blobby triangular thing) that stretched into each corner to the extent defined by that organization.  And I think it's fair to say that in most organizations, the shape would likely be subject to frequent revision as the organization and its product and market situations evolved.

Recently, though, I've added a fourth point to my diagram -- the Business.  Some of this stems from my time as a GM, owning a P&L, and some is just the result of moving up the PM ladder over the years, where responsibilities shift from the tactical to the strategic -- or maybe just expand to require both.  And it's a useful inclusion for the PM function, if not necessarily for every PM on the team.  Adding this dimension makes the PM team accountable for the results of their work within the other three axes, and also provides an important lens through which the PM's should look at everything they do:
  • What, really, is the market opportunity, and which are the right problems to solve?  It's my hide on the line if we pursue the wrong opportunities.
  • What, are the true must-have's we should spend money on?  It's my hide on the line if what we deliver doesn't work right, or doesn't find enough market interest to buy.
  • How can I be sure that the rest of the company is ready to push forward with what we've built?  It's my hide on the line if Sales doesn't pursue opportunities to sell it, if the service quality around the solution is poor, and customers are both few and unhappy.
And so on...  These are important questions that may never be asked if the PM's are thinking mostly about features and demos.  The ultimate judge of an offering (and thus the performance of its product manager) is its financial performance against the established goals.  And so a square it is, not a triangle, and with a 4-pointed blob defining a given role against all possible responsibilities:

I'm not sure how much value these diagrams really have out of the context of a white board -- PowerPoint seems to formalize them inappropriately to me -- but they've been useful framing tools with a pen or marker.

So, back to the question -- what is software product management?  A product manager is a custodian of a business.  The PM's job is to make sure that there is an opportunity worth pursuing, that the people building the solution for that opportunity get it right, that the people who need to execute the solution and bring it to market get those jobs done successfully, that customers are delighted and kept happy, and ultimately to make sure that all of that effort was worth making, as judged by the financial success of the product.  There are a thousand different tasks and activities that fall into getting all of this right, but focusing on those risks diminishing the role and its strategic importance.

That's my simplified take on the job.  How do you see the role?  I'd appreciate your opinions, and I thank you for reading.

All for now,


Tuesday, September 28, 2010

Best job ever -- really?

OK, so maybe I'm biased.

I've been in software my entire career -- over twenty years, now, though that hardly seems possible.  And for three quarters of that, I've held Product Management roles.  I've been a sole PM at a small company, a member of a large PM team at a large company, managed small teams, coached people new to the role, and twice established PM as a discipline in emerging companies.  I did step away from managing products a few years ago, taking a promotion to serve fifteen monts as General Manager for a line of business.  But I found during that stint that a GM is really a lot like a PM, just with a broader focus.

So if it's not everyone's idea of the best job in the world, it's one I've poured myself into for a very long time, and one that I've found to be fun, challenging and immensely rewarding.  I'm also very good at it, at least in the way I've experienced and defined the role.

I've been blogging for two years, now, with my personal blog, Bronze Gears.  I've thought about starting a professional blog for a while, and I even set up a second blog on my Blogger account last year.  I never got it off the ground in a meaningful way, though, I think mostly because I wasn't sure what to write about.  But 2010 has been a substantially different year for me than 2009, and my experiences this year have given me a lot to think about with respect to my chosen vocation.

I left my most recent employer (one of only three, in that 20+ year career) at the end of April, just before they merged with a historical rival.  My reasons for leaving are numerous, but the most important one is that it was time for a change.  I looked for a bit before I left, and then started looking seriously over the summer, and am still looking for just the right fit.  So yes, that means I'm available, if you're looking for great PM talent!

The search has been a lot of fun, and I've met some great people and had many really energizing conversations.  In preparing for interviews, I've needed to think about the different legs of my career -- to figure out how to frame them in describing who I am as a professional.  And in poring over the details of my most recent role, I came to understand just how great a treasure trove of experiences it was.  It was one of the most challenging environments I've ever been in, and at times an extremely difficult place to work.  But I left a much better PM than I went in -- and I'd argue that I was pretty damn good at the start.

Those experiences and what I took from them will form the basis of what I'll have to offer, here.  And at their core is my role in helping move a product and a company from an on-premise delivery model with a traditional licensing model to a Software-as-a-Service (SaaS) delivery model with a subscription model.  The lessons are many, and I invite you to share your own in comments on my posts.  If everything goes as planned, at some point I'll be able to stop looking back for nuggets to share, and will be able to draw from the lessons of my next job.

Next time, I'll get started for real -- digging into the best job ever.  I'm looking forward to it, and thanks for joining me.

All for now,