Category Archives: Development

Crowdsourcing ideas for Canada’s future

Yesterday, I posted Canada’s Innovation Gap (part 3) where I discussed some ideas for solving the lack of innovation that exists in Canada.

This weekend, the Liberal Party of Canada is hosting a conference in Montreal focusing on Canada’s future.  The conference is called Canada at 150: Rising to the Challenge. It’s a non-partisan conference bringing people from different industries,  political views and areas of Canada together to discuss 5 key challenges related to the nation. Those challenges are:

  • Jobs Today and Tomorrow: the Productive Society of 2017
  • Real life issues for Canadian families: How do we care?
  • Energy, Environment, economy: Growth and Responsibility in 2017
  • The Creative and Competitive economy
  • A strong presence in the world of 2017: Commerce, values, and relationships

What’s great about this is the relatively open process they’ve used to get the participation from all parts of the country. Clearly with an agenda like this, the topic of innovation was discussed.

The following panel discussion, along with Q&A is well worth watching. Some really frank and honest comments are made.

(click on the image or click here to go to the video. NOTE: The first minute or so is in French and then it moves into an English discussion. )

A great comment from the early part of the discussion came from panelist Roger Martin, Dean of the Rotman School of Management, University of Toronto.  He gives his definition of innovation and invention.

Innovation does not equal invention.  Invention is producer driven. Someone says, I want to have some kind of gadget. And they dream it up in their lab or basement or garage. And it may not be of interest to anyone else. That’s invention.

Innovation is driven from the user or the consumer side…it’s about improving the experience of the end user or consumer.

Note the point that innovation is driven from the user or consumer perspective. It doesn’t mean they drive the innovation, but that their needs must be central to the innovation process.

Later on, when answering a question about the role of taxpayers and the government in helping spur innovation, Martin says quite bluntly:

I made the distinction earlier about invention and innovation. The problem for Canada and it’s been this way for a long time is we don’t have an innovation policy in Canada. Unless you call benign neglect a policy. We have an invention policy and in fact all of our money goes for invention and that’s the gross error.

I love this statement as it’s so straight forward and unapologetic. We need more people like Martin to speak out this way.

I strongly recommend listening to the full discussion. They discuss value of design in new product development, the reasons for lack of commercial success for Canadian “invention”, the sad state of the VC industry in Canada and much more. It’s very honest and in many places quite astute, and I feel, long overdue.

Saeed

Advertisements

Guest Post: Web Product Management 101 for “Offline” Managers

NOTE: The following is a guest post from Thomas Fuchs-Martin. If you feel inspired to write a guest post of your own, click here to find out how to submit it to us.

—–

You are an experienced software product manager and you are thinking about developing your first web product?

Great! This blog post is written especially for you!

Be aware: The fact that you are about to manage a web site really changes a lot in your product strategy and the management processes that you know from “offline” products. I have prepared a crash course for you – defining terms and phrases that you will need to understand as part of your web product management role:

CPC, PPC etc.
Due to the fact that there are many different kinds of business models that exist in the web world, a lot of abbreviations have become very common (I am not really sure if that is a good thing…), particularly when it comes to advertising!

Most common is PPC (Pay per Click) which describes a model where the advertiser is charged only when a user clicks on their ad. Google Adwords is the most well known example of this. The payment amount or CPC (Cost per Click) defines the price paid by the advertiser for each click.

Even if your business model will not be advertising-based, the day will come that you either want to advertise your product on other sites or that you want to implement some advertising model on your site. You will need to understand the common models to avoid (expensive) mistakes.

Emergency Deployment
A website has to be up and running all the time, and there can be numerous backend servers and database needed to do this. You’ll need to schedule regular maintenance time to handle patches and upgrades. But, if you encounter a large bug on your production site or the site is not working at all, you might need to interrupt the usual release cycle and schedule an emergency deploy to fix urgent problems. In the worst case you will have to adjust the timings of your product plan because of these events.

SEO
In “offline” product management you basically have to think about how to create a great user experience. In web product management you have to think about search engines, too. Unfortunately users and crawler bots don´t always have the same needs which makes SEO (search engine optimization) quite interesting. SEO is the process of improving traffic to your site from search engines.

Important: Do not get the idea that you can completely outsource this! The majority of modern internet business models are based on good SEO, and your product planning will be affected by SEO requirements right from the start!

Private Beta / Public Beta
That is possibly one of the biggest luxuries that you will have as a web product manager. You can launch your product while it is still in beta-state. You just put a “beta” label beside your logo and a feedback-button somewhere prominently on your page and see what happens – this is called “public beta”. If that is too crazy for you then you can password-protect your site and only share it with selected users – that is a “private beta”.

Very important: Get the idea out of your head that your product needs to be perfect before you can launch it! There are many minimalistic and half-backed products out there that are pretty successful. Early release beats perfectionism and the minimum viable product beats the over-featured product. Remember the early days of Twitter?

Cookie-Issues
Well this has nothing to do with food! In the web a cookie is just a piece of data that will be saved at the client computer. A bunch of very common features rely on cookies such as online-shopping or login-sessions etc.  It’s important for you to know that features that rely on cookies can be very painful to test because the features can behave differently depending on the client´s configuration of browsers etc.

“See you at 2 am!”
Well, in theory you can release a new version of your web product at any time you want. But maybe you don´t want to risk downtime during the peak periods of the website. So for bigger releases and maintenance operations, the early morning might be the only time-frame of the day with low traffic …and you and your team are working hard while everybody else is sleeping! If your website has a huge amount of traffic you might even consider to launch at the weekends, because usually the traffic is lower during those times.

Browser Issues
Creating a useful user interface for websites is a hard job. In the offline world you “only” have to think about which operating system and screen resolutions your target customers have. In the web you also have to worry about different browser versions, browser security & privacy settings, pop-up blockers etc. It is almost impossible to create a complex website that will work with all browsers.

My recommendation: Focus on the most popular browsers and be minimalistic with the product features. The best way to figure out which browser your web product needs to support is to take a look in your web analytics. The diversity of browsers can vary significantly depending on the target group or target-country of your website. At minimum, your site should support Firefox, Internet Explorer (even the old IE 6 is still a common browser) and Chrome.

Web Analytics
You will have lots of information about the users of your product – for free! Google Analytics is the most common free web analytics tool that will provide interesting information about your users. For example: number of visits, pageviews, average time on page, country, browser version, screen resolution, bounce rate, top landing pages and much more. Get familiar with these analytics tools and identify the strong and weak points of your product!

Website Speed
Even in the age of high-speed internet connections you need to have a fast website! Not only do users like fast websites, search engines love them as well! Listen to what Matt Cutts from Google says about this:

[Youtube=http://www.youtube.com/watch?v=muSIzHurn4U]

I hope this crash course will be helpful for you to kick-start your web product manager career!

Thomas Fuchs-Martin is web product manager & SEO at the Spanish internet start-up nuroa.es – More articles about web product management can be found at his blog: www.webproductblog.com

What Origami can teach us about Product Requirements

Tom Grant has started an interesting series of posts entitled Against a Grand Theory of Product Management. The articles are interesting reading, but make sure you have your thinking cap on when you start, because Tom is discussing an important but rather abstract topic.

He pulls in references ranging from Middle Range Theory (something I’d never heard of before) to Darwin’s theories (something I think we’ve all heard of but probably don’t adequately understand) to help convey his points. I had to read the posts a couple of times each to better grasp the specifics of his arguments.

In Part 2 of his series, Tom asks:

If someone can figure out why even the most meticulously written and reviewed requirements don’t stop some tech companies from making products that their users don’t like or can’t understand, that’s a big contribution to our little field of study. Best to have more middle-range theory before even thinking about the GToE [Grand Theory of Everything].

This is a great question. But before I answer it, I want you to watch the following video. It is from a TED Conference talk given in February 2008 by Robert Lang. Not only is this a fascinating video, but as you’re watching it, keep Tom’s question in mind. Don’t read on though until you watch the video. 🙂

[BTW, if you are impatient and read ahead, the important stuff starts at about 2:30 in the video.]

Lang talks about the evolution of origami, that took it from a traditional Japanese art form that most of us associate with creating things like this:

and turned it into an art (and science)  form that allows people to create things like this:

And what caused that evolution? In Lang’s words, the answer is “mathematics”, or more specifically, the creation and utilization of a set of rules that provide a language for defining what can and can’t be done in origami.

The rules define the crease patterns — the lines along which folds are made — in the paper. And there are 4 rules:

  • 2-colorability — any valid crease pattern can always be coloured with only 2 colours and will not have the same colour in two adjacent areas.
  • modulus (M-V) = +2 or -2 — at any interior vertex, the number of mountain folds and the number of valley folds will always differ by 2
  • For any vertex, the sum of alternate angles around that vertex will always be 180 degrees. e.g. a1+a3+a5 … = 180 degrees  & a2+a4+a6… = 180 degrees.
  • No self-intersection at overlaps – a sheet when folded cannot penetrate itself

[Note: if you don’t understand these rules, watch the video. 🙂 ]

Now these 4 rules define the properties of valid crease patterns, but there’s still something missing. How can those rules be applied to create sophisticated origami? In short, what goes in the box? (see 4:40 of the video)

Lang discusses that as well, and provides this diagram:

In short, the physical subject is reduced to a tree figure defining the key components (“flaps” in Lang’s terminology) of the subject. In this case, those are the legs, antennae, horns etc. of the beetle. That’s fairly easy.

Then some process must be used to take that tree-figure and create a base form for the final origami. He calls that the hard step.

And finally the base form can be refined to create the finished model. That’s fairly straight forward.

The “hard step” is accomplished using the rules defined above and the language for applying those rules. Given those rules are mathematical in nature, they can be written precisely and unambiguously and then executed to create the final model.

What does this have to do with product requirements and Tom’s question?

When looking at product requirements, there are analogies to Subject-Tree-Base-Model example given above.

  • Product Managers investigate  real world problems, needs, scenarios etc. (Subject).
  • They then take their learnings and create abstracted representations of them (requirements) using artifacts such as problem statements, personas, use cases and user stories (Tree)
  • These artifacts are then used by engineering teams to create prototypes and mockups etc. to ensure that the requirements were understood and addressed in the product. (Base)
  • The final product is built, tested, tweeked etc. with the appropriate “fit and finish” before being released. (Model).

Sounds pretty good so far right?

But herein lie the problems.

  • There currently is no language for requirements like the one defined for origami, that can precisely and unambiguously convey what is needed and define that in a way that ensures it can be built.
  • Requirements should be implementation neutral, but as we all know in technology, the ability to fulfill a requirement can often be limited by technology choices and decisions that were made well before the requirement existed.
  • Other constraints such as time, resources, knowledge, legalities, finances etc. all factor into how well a requirement can be met, or perhaps if it can be met or not.
  • In many cases requirements contain unknowns or ambiguities that are filled in by assumptions during the development process. This is a reality of developing products in a business environment.  In the origami situation, this is would never happen. A model (like the stag beetle) can only be built when the full crease pattern is defined.
  • There is no concept of people “liking” or “understanding” the origami in Robert Lang’s rules. i.e. Tom Grant asks about why companies build product their customers don’t like or understand.

This last point is key and deserves a little more discussion. What people like and understand is complex and is not static. In general, what people like is based on overall experience and emotion. It is not something that (currently) can be defined in a set of requirements.

i.e. users of this product must feel giddy with excitement the first time they use this software

So, can origami teach us something about product requirements?

Absolutely. The origami path from Subject->Tree->Base->Model forms series of transformations that is akin to the requirements gathering, communication and development process used when creating products.

Once a set of clear foundational rules for origami were defined and understood, not only did they open up new possibilities for forms never thought possible, but those rules formed the grammar for a language that makes precise and unambiguous communication also possible.

There is almost certainly a set of rules and language for precise definition and communication of requirements, but it has not yet been clearly formalized. That is likely a necessary stepping stone in the maturity cycle of product development.

But even with that requirements language, changing market landscapes, customer preferences and needs, technological, resource and time constraints will all work together to make product success a “grey box”, where those with great vision, insight and execution are likely to succeed but never guaranteed that success.

Saeed

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Support the Cranky PM at BoS 2009

While there are many places I’d love to be in mid-November, there’s definitely one place I really want to be (but can’t)  on Tuesday November 10, 2009.

And before I say anything else, let me tell you this is not a paid promo piece from the PR firm that promotes the Cranky PM. 🙂

Where would I like to be on Nov. 10? I’d like to be in San Francisco where the Cranky PM will appear live (from 2:30-3:00)  and speak at the Business of Software conference.  Last year, Steve Johnson was the big hit at the conference. This year, let’s help the Cranky PM!

As readers of our respective blogs may have noticed, We’ve had an ongoing, healthy online conversation(!) over the last couple of years. Here are a few from this blog:

And here are a couple from hers:

Now, I’m sure there will be people who go to the CrankyPM’s session simply for voyeuristic reasons. What does she look like? Is she a she at all? Do her legs look like those in the picture? Is she as funny in person as she is on her blog? etc. etc.

I think people should go there to support her. I’m pretty sure that being a popular anonymous blogger has it’s benefits. But being a frequent speaker at conferences is NOT one of them.

So here’s a tip of the hat to the Cranky PM, and whether she decides to reveal her identity or not, try to support her by attending her talk.

And for those of us who can’t be there, please live blog or tweet it if at all possible! 🙂

Saeed

Product Management Metrics (part 2)

In Part 1, I defined the mandate of Product Management as:

Product Management’s mandate is to optimize the business at a product, product line or product portfolio level over the product lifecycle.

I’ve emphasized 3 words: optimize, business and lifecycle.

Optimization is the process of changing a system to make it work efficiently within a set of given constraints.

Fundamentally, this is what Product Management is all about: how to invest limited resources to deliver competitive products to market, that are in line with market demands and expectations and then working with other teams to better enable them to reach their targets that make up overall business goals. 🙂

Product Management must always keep business goals in mind and work to achieve or help achieve those goals within the context of the products or product lines.  Business goals are typically related to revenue, expense, customer acquisition, market share, geographic expansion or organizational improvement. This is a sample list of goals and doesn’t imply that Product Management must focus on these areas.

It’s important to keep in mind that business goals differ across the product lifecycle.  A product lifecycle can be defined as having the following stages:

  • Development
  • Introduction/Launch
  • Growth
  • Maturity
  • Decline
  • End of Life

There may be variations on these stages, but this represents the major phases that a product will pass through. And the goals and objectives for the product will vary at each of these stages. For example, the Development phase usually is pre-revenue. In this phase, Product Management is focused on understanding market needs and working with various parties (internal and external) to create a product or solution that addresses those needs.

With Launch, the goals for the product can include initial customer acquisition, validation of the product in the market, educating influencers, generating awareness etc. Revenue obviously becomes a major factor after Launch, as do goals such as customer retention and ongoing competitive differentiation. The other phases — Growth, Maturity, Decline and End of Life (EOL) — all bring their own challenges, constraints  and objectives.

Given the changing objectives over the product lifecycle, the goals of Product Management will change, activities to achieve those goals will change and the metrics that are used to measure them will change.

In part 3, I’ll get more specific, and lay out a model that people can apply to their products or product lines. It is important to note that there is no “one size fits all” solution here. Only at the highest level of business reporting– customer acquisition, revenue, customer retention etc. — can there be a single set of metrics for most products.

Because of the breadth of potential technology products — e.g. SaaS vs. Licensed software, a consumer product vs. a B2B product, infrastructure vs applications, a retail product vs. an OEM product  etc. — specific metrics across the lifecycle will vary.

Department vs. Role

I do want to make take a few moments to address a question related to role metrics vs. department metrics. That is, the metrics used for measuring a Product Manager, vs. the metrics used for measuring Product Management as a whole.

In small  companies, there may only be a single Product Manager for a given product or product line.  I’ve been in that situation myself a couple of times. In those cases, metrics for the Product Manager are pretty much the same as that for the Department.

But in larger companies, where there truly is a Product Management team, most likely with differentiated roles for PMs (e.g. Technical Product Manager (TPM) , Sr. Product Manager, Director Product Management etc.) the metrics that would be used to measure individuals likely would be different that those for the entire team.

For example, a TPM would likely spend much of their time working with Engineering during a development cycle or researching technical issues for upcoming releases, whereas a Director would be more focused on overall product strategy, business alignment, strategic partnerships etc.

The Product Management team may be measured on product revenue, delivering a new release successfully etc., but individuals in that team would have other role specific metrics tied to their individual activities and responsibilities as well.

As mentioned earlier,  in part3, I’ll get more specific and present a model that could be applied or adapted by Product Management teams.

Saeed

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Canada’s Innovation Gap (part 1)

While this post is targeted at the innovation, funding and technology issues in Canada, it may apply to other geographies as well, particularly if you don’t live/work in technology hot spot such as Silicon Valley or Boston or Banglalore etc. This is a topic that is very dear to me, given that I currently live and work in Canada, but spent 6 years earlier this decade living and working in the San Francisco Bay Area.

A couple of weeks ago, there was an great article in The Globe and Mail newspaper (one of Canada’s leading daily papers) entitled Canada’s innovation gap. The article, by Konrad Yakabuski, outlined what I think is both an accurate and troubling picture of the state of R&D and innovation in Canada. Here are some highlights from the article.

  • Innovation in Canada is in deep trouble. Productivity is stagnating; the manufacturing sector in imploding, and the government policy makers seem asleep at the wheel.
  • Once the flagship of Canadian high tech, Nortel is being dismantled and it’s best assets are being sold to foreign companies.
  • While Blackberry maker Research in Motion is a true global leader, and often cited as an example of what is possible in Canada, there are few if any other Canadian companies that can be held in the same light.
  • Canada’s economy is heavily resource based, and those companies spend very little of their revenues on R&D, even though they made enormous profits before the recession due to high commodity prices.
  • While Canada was moderately successful at moving from a provider of raw resources to foreign countries to a more modern economy, the last 10 years have reversed that process.
  • Historically, the  small group of elites that got rich on these resources controlled the political levers to ensure nothing changed. [Note: I personally think this still applies although not as much as it once was]
  • Innovation is the only sure way for Canada to be more productive.

I could go on. It’s a great article, and it should be a wake up call to every politician and business leader with any sense of commitment to the future and well-being of this country.

Change is a process

Change is needed on a lot of fronts. While many politicians are quick to highlight that the Canadian economy has faired better than other industrialized economies in the current economic crisis, it doesn’t change the fact that there has been a huge disruption in the Canadian economy, widespread layoffs, plant closures and bankruptcies.

Keep in mind that billions were spent to help manufacturing companies, particularly automakers with vociferous unions, but little if any was spent or allocated to help technology companies or create environments to make investment in high-tech much easier. A quote from the article:

“Canada is not being productive because it’s not being innovative,” said Robert Brown, chief executive officer of Montreal-based CAE Inc., the world leader in aircraft flight simulators and training. “A lot of innovation occurs at the interface with the customer. But when you look at the make-up of Canada’s economy, with so much dependence on resources, there is less contact between [our biggest] companies and end users.”

I think this is a polite way of saying that there are a lot of companies that are more than happy to cut down trees or dig minerals  or pump oil out of the ground and then ship it off to some other country to be processed and have value added to it.

Aside from being innovative, Canada needs to look to add significant value to whatever industries it has. We have great R&D minds in this country, but there are problems in productizing the research and funding and scaling businesses.

My personal experience

I moved to California back in 2000 to seek better opportunity – i.e. professional and financial gain — than I could find here in Canada. One of my best friends from high school — a brilliant guy who did his undergrad at Harvard and his Ph.D at Princeton, is now a research professor at another Ivy League school, even though he really wanted to come back and live and work in Canada. He told me back in the early 90s that the opportunities just weren’t here for him. He’s a great example of the brain drain this country faces on a regular basis.

I moved back to Canada a few years ago for personal reasons and I have to say it wasn’t easy coming back. Aside from the nicer weather in California, I knew that my career opportunities would be more limited than they were there.

And trust me, there is a huge difference in the technology industry here in Toronto and that of Boston or San Francisco. Everything from the amount and quality of investment funding, to the networks of people with connections into technology giants to the breadth of skill sets of individuals, and even to the aspirations of company founders are very different.

We’ve got brilliant people

I’m not slagging anyone here. There are very bright, dedicated and passionate people here. I’m proud to know a number of them. But when it comes to goals, too often a Canadian VC or company founder sees a $50 million exit as a big win, whereas in the US, that’s on the low end of their success scale.

And that exit often means jobs moving to the US or offshore. In many cases the key people in the acquired company (the bright, dedicated and passionate ones) move down to the US to work “at corporate”, and the brain drain continues.

I don’t want to paint a completely bleak picture of the situation here. As I said earlier, there are very bright, talented and passionate people here. In fact, after I moved down to Silicon Valley in 2000, one thing I realized was that the people down there are not smarter than the people here.

But the level of investment financing, the personal networks of skilled people, the institutions like Stanford and Berkeley all provide a critical mass of infrastructure that enable risk taking and innovation on a scale we don’t really have in Canada. The infrastructure and culture there pull bright people from other parts of the country and other parts of the world.

The issue is not the people here in Canada, it never has been. It’s all the other business levers that innovators need to “nail and scale” their businesses to be world leaders. I personally think the co-founders of RIM (Mike Lazaridis and Jim Balsillie) should be viewed as national heroes, on the same scale as Wayne Gretzky or Gordie Howe (famous hockey players for those of you who didn’t grow up on hockey!).

I’m sure Mike and Jim had numerous incredibly lucrative offers to sell their company over the years. But they didn’t. They held on, grew the company, fought off lawsuits, challenged rivals and continued to innovate and create a global leader based in Waterloo Ontario. And just recently RIM was named the fastest growing company in the world by Fortune magazine.

So what can be done to close the innovation gap? Konrad offers some solutions in his article. I’ll get more into that in part 2.  But in the mean time, I’d like to hear what you think, particularly if you are here in Canada, or are Canadian and are living/working outside of Canada.

Saeed

Related Article:

Canada’s Innovation Gap (part 2)

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Guest Post: There’s no such thing as MEDIUM

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

NOTE: The following is a guest post by Tzvika Barenholz, a Product Manager living and working in Israel. If you feel inspired to write a guest post of your own, click here to find out how to submit it to us.

We all know the situation: you’ve collected a bunch of product requirements, put them into a nice excel sheet or clever table-like GUI front-end; you’re all psyched about making the big decisions, prioritizing and leading the product to the proverbial “next level”. You sit in front of the screen, crack your fingers, stretch a bit and place your hands in the typing position.

“First item, feature xyz” – yes, you say it out loud, you’re psyched remember? – “First column, Importance” (or priority, or appeal, or whatever is your favorite alias for customer value)

OK – now what *was* the priority of feature xyz?

Let’s see. A couple of big customers have asked about it in a recent expo, so probably high, right? Then again, it’s one of those things that make the product more complicated, so call it low. Having said that, it would really improve average sale price, which is aligned with the five year plan, so high it must be. But what about breadth? It really would only appeal to a fraction of our customers. Back to low again.

And on, and on.

Exasperated, you note that after 20 minutes you’re still on item #1 out of 37. It’s looking more and more like a long night of pizza and coke with the developers. The next thing you know, there’s a little voice inside your head that whispers: make it a medium!

Of course! How foolish you’ve been to overlook this possibility before. A medium is right in the middle between high and low. It’s the perfect answer for what seems to be neither here nor there, or both here and there. Your right index finger then makes it merry way to the m key.

But STOP – you’re just a moment away from falling into a trap as old as the hills. Why? Because there is absolutely positively no such thing as a medium, except maybe as a shirt size.

“Medium” is a shirt size, not a useful priority rating

Prioritizing something as medium is just a way chickening out of making a decision. If you don’t have enough information to make the call, go get the information, then make the call. If you’re piling up different qualities like “broad appeal”, “helps sales”, “improves margins” and “technologically strategic”, then by all means, add 4 columns, fill them out with highs and lows (or yes or no, for the more advanced practitioners who know how to make an even cleaner cut), and then rebuild the priority column as an index composed of them all.

But whatever you do, don’t just cop out. Don’t just type medium and move on to the next item, or you will end up building the wrong things for the wrong reasons.