Product Strategist: Aspect-Oriented Programming

Out on Twitter earlier this week, Scott Sehlhorst mentioned something about Object-oriented programming (OOP), so I added Aspect-oriented programming (AOP) to his list. Then, we tweeted about that. He asked for my blog post on this subject. But, with my blog host down, I'm at a loss as to where to point him. So today, we will explore AOP, and more particularly, what it means to product strategy.

AOP originated at IBM. Initially it focuses on cross-cutting concerns like security that turn up in our non-functional requirements, as opposed to our functional requirements that describe the logic of the automated and automating domains implemented via OOP. Java extensions supporting AOP exist.

AOP in non-invasive. OOP provided a huge improvement in encapsulation, or coupling and cohesion, over structured programming. Encapsulation puts code inside black boxes. AOP doesn't mess with the stuff inside those black boxes. The messaging of OOP happens outside the encapsulations. AOP intercepts messages, triggers processing in the AOP code, and then sends the message, unchanged, on to its intended recipient, so the execution of the OOP code continues uninterrupted, and unchanged.

As product managers, we have to remain non-invasive with respect to the implementing performed by our team members. Cross-cutting concerns can be left to your technical architects. But, when it comes to long-term maintenance, evolution, and testing, AOP offers distinct advantages to the software vendor.

When your team finds bugs, they get invasive to fix the bug, and introduce other bugs. A bug fix doesn't necessarily reduce your bug count. A bug fix may insert more bugs than it fixes. QA does full regressions after bug fixes, because you never know where a bug will show up in once clean code. Those full regressions are limited by your budget. They only reach so far. And, we all know that there is always another bug. Hackers are actually testing your application beyond the economic limit (budget) of your company. Hackers have no economic limit, so they will find the next bug before you or your customers do. AOP can help here.

If bugs are corrected non-invasively, that clean code never has to have the same tests run on it again. So instead of using your test budget on the same old tests, you get to run new tests that test deeper and wider and expand the reach of your economic limit. You would have to create new tests for the fix, but the scope of those tests would be much narrower than those run in a modified full regression.

Your application would take on an object-within-an object architecture. OOP already can be viewed that way. JavaScript in its DOM processing is organized in this manner.

You would code the core functionality. Once released, the next upgrade would be coded as a non-invasive extension where AOP would provide the integration between the core and the upgrade layer.

In this figure black represents the core code or initial release. The blue represents the subsequent release. The red represents the AOP interface between the core code and the code for the subsequent release.

In this figure, the curves from the regression tests have been added. While coding the subsequent release, additional tests were run on the core code. The code for the new code is tested as well.

The regression curves in the figure reflect a reduced test budget. If the test budgets were held to ordinary issues the volume of tests would be some multiple of that shown for the prior tests.

The economic limit of the firm, shown in gray, can be moved from the testing bought in the initial release to additional test coverage bought during the upgrade effort.

AOP can reduce time, money, customer dissatisfactions, and emergency efforts focused on security issue responses. Consider AOP a strategic option. Explore it today.


Any comments? Leave them here, or email them to Dave44000@yahoo.com. Thanks.

Alignment

One of the best ways to build your team involves getting them aligned with the goals of your team. It's not something that happens in startups.

It did happen long ago in the big corp, because we had to write MBOs. The organization had goals. We had goals. If we could find a way to frame our goals in terms of the organization's goals, we won. Aligning centers around this framing.

One of the prerequisites is knowing your people. I can remember how one manager hired a friend, and then gave them the coolest project to work on. But, the friend didn't think it was cool. He hated it, because it detracted from the skills he felt made him valuable. He was never going to use the skills he had to learn while working on that project. I would have seen it as a growth opportunity. I knew more about it than my coworker. I provided the contact info for the external contractor we used for things beyond the co-worker's scope. The coworker was ready to quit over the assignment. Alignment was messed up across our team, because someone was taking care instead of giving care, but more importantly, because the manager didn't know his people, even his friend.

Alignment doesn't mean that everyone will pull in the same direction, or for the same reasons. But, everyone can make a contribution through their own alignment.

The figure shows how a team aligns around the goal of getting the product shipped. You can substitute department names if you like.

The point is what the people get out of the work, out of their contribution. They should be serving themselves, as well as their line manager and functional unit.



This gets particularly messy if a team member is assigned to several projects and contribute only a small proportion of their effort to your project. Regardless, you might find that your team members give you more than they give those other projects if you and them have gotten alignment on their goals where other managers have not.

The better you know your team members the better able you will be when you help them to achieve alignment with team goals.

The better you know your peers and members of all of your contributing functional units, the better able you will be to get alignment with them. It's not so much knowing the function, and knowing the role of that function in your firm as much as it is knowing them as people. They can buffer the typical organizational conflicts if they see that as being in their best interest.

To find the time to know your people, never eat alone, and manage by talking around. And, don't talk project. Talk to the person. Management talk in the office, leadership talk everywhere.

And, please, don't ask me how "I" am if you want a project status. "I" am not your project. Unless, you're a bud, I'll say I'm fine, even if ....

If you don't think you have time, you really don't have time not to.

Leave some comments people!

Blue Ocean Strategy and the Technology Adoption Lifecycle

I finished "Blue Ocean Strategy," http://bit.ly/acHSD recently in advance of the next meeting of the Smarter Product Managers book club, hosted at http://www.booksprouts.com/. I tweeted about finishing the book in the #pmv and #prodmgmt tweet streams after which a discussion broke out. The discussion centered around the difference between a blue ocean, red ocean, and white ocean.

The book defined the red ocean as the commodity goods market. The blue ocean boils down to a hybrid ocean consisting of elements from red ocean goods and services targeted to non-buyers of the firms previous red ocean market. The white ocean wasn't really described in the book, but came up in the twitter discussion as a brand new market. The twitter discussion defined a white ocean as an ocean created by technological innovation. The book was big on how technological innovation could not persist these days, so it provided no real business proposition. This to set the stage for the need for value innovation.

The business community typically sees disruptive innovation as being very risky. But, that risk originates in the red ocean tactics that are typically used, and which really don't suit a disruptive innovation.

A blue ocean strategy would be an alternative to value-basing, mass customization, relationship marketing, demand-side services, and launching a new technology into a battle for market leadership of a new category. The whole blue ocean discussion centers on the creation of a new category without disruptive technology.

Since I think in terms of disruptive technology, I put everything into the context provided by Moore's technology adoption lifecycle. It contextualizes the category from birth to death. Moore's late market turns out to be the red ocean.

This figure shows Moore's technology adoption lifecycle as being the small normal curve to the left. The larger normal curve represents the category after it has been acquired by a large blue chip company.

The small curve would represent the Internet back in the dot boom. The larger curve is the Internet after the telcoms bought up the once disruptive Internet companies. In one particular report this larger market was ten times larger than the initial market.

In the diagram, I annotated the red oceans that the category or market is characterized as. The blue arrows show growth anticipated in each category. One a category enters the late market, growth is at an end. The contraction in the market is demonstrated by the brown arrow in the larger blue chip market. This lack of growth motivates the construction of a blue ocean strategy.

Moore talked about growth ending on the entry to the late market. Price-based competition begins earlier. As shown in the next figure.

It is price-based competition and the proliferation of fast followers that drive growth negative. On the figure the gray area on the left represents the tornado. The tornado is where the fight for market leadership is fought. The market leader emerges from the tornado with an advantage over the rest of the field. The yellow area depicts where price-based competition and fast following begins. Again, the late market is depicted as a red ocean.

The blue arrow depicts the interval where the most rapid growth occurs. This is also the best place to IPO. If your IPO is delayed into the red ocean region, you will find that the premium paid on your IPO falls to zero. There is no upside in the red ocean. The expectation is that you will make lower returns in the red ocean.

The far left portion of the disruptor's normal curve (white area under the curve) shows where any white ocean or new market or category is created though disruptive technology.

So you find yourself in the red ocean, and it's time to construct a blue ocean.

First, you find an unserved population. Then, you take capabilities in your current business, extend them (black), throw some away (red), and add capabilities (brown) from other red ocean categories together to form a new hybrid (blue) category that serves that unserved population.

A disruptive technology would likewise seek and serve an unserverd population, unserved by the current categories, or over served customers in an existing category(Christensen). This sets Moore's technology adoption lifecycle as a competitor for blue ocean strategy formation.

The red ocean became red as differentiation was wrung out by competition and the convergence of competitors and their co-evolving markets. Competitors eventually emerge in a blue ocean and gradually turn it red, as depicted by the purple edge to the right of the blue ocean.

The book talks about how the blue ocean can be extended through IP protections and hard to copy capabilities.

The book establishes three criteria for blue ocean formation. More on this in a later post.

What do you think? Leave a comment. Thanks!