Skip to main content

The dynamics between marketing and software development

This post has be "baking" in the back of my mind for quite a while now and I think it's almost done baking.

I got the idea to write this post while I was working at my previous employer. There I would develop some pretty complicated functionalities that took a long time to develop with quite some effort. And after that I was frustrated because those functionalities were hardly used anywhere. So my question after that was why did we develop them anyway?

After those incidents I happen to read about the release of some new mobile phone. I think it was the release of Samsung Galaxy S9. It had around 98% of the same features as the previous model, the S8, including the main functionalities used by everyone. The new functionalities were hardly used by anyone. But on the other hand it gave the consumers a reason to upgrade their phone. And it gave other consumers that were looking into buying a new phone a reason to buy a Galaxy S9 over another phone from another brand.

As a consumer if I have to choose between 2 phones from different brands, even if both phones do the things I am most likely to need I would still choose the phone with more additional features over the other phone with less features because why not?

This made me realize that in the end the software that I was building was a piece of technology exactly like the Galaxy S9. And just like the S9 it also had a designated market segment with various consumers. And these consumers have a wide variety of products to chose from, including the one I was working on. So just like the telephone mentioned earlier, I was giving the customers additional reasons to buy out software by implementing these functionalities. They were actually designed to spark the interest of the customers and make them say "Wow!". Even if they were very unlikely to use those features, the simple fact that our product could do those things would make a very good impression of the product to our customers and convince them to buy our product instead of another competing product.

But one major caveat of this approach is that it works mostly with consumers that already made up their mind to buy a new product. Attracting existing customers that do not explicitly want to upgrade to a new product is harder. I think this approach is useful when you have a new product that you are trying to introduce to the market.

Now this isn't a general rule and in some cases you add a feature that only used 1% of the time because you have a key existing customer that demanded that feature and you can't afford to neglect his demands. Actually this can be turned into something good because if that customer is important or big then you can turn his case into a success story which then can be used to attract even more customers. I think at my last job we had a customer like this that was at the forefront of our product. And now that I think about it at my new job, there isn't just one such customers. There are several of them and they share their testimonials on the main product page. If you can get even one or two of these big customers to use your product and share their stories, you will gain traction and others will also start to adopt the product.

In the end, there is actually a pretty tight relationship between the people that market a product, the people that design that product and the people which actually develop it.




Comments

Popular posts from this blog

Some software development common sense ideas

 I haven't really written here in a long time so it's time to write some new things. These are just some random common sense things that seemed to short to write about individually but seem really interesting and useful to me or other people 1. There is nothing fixed in software development, all things vary by circumstances and time Remember the documentation that didn't seem that important when you started the project, well after a couple of years one the application has grown and become really complicated, no one actually knows everything about the application anymore. So now you really need that documentation. What happens if you suddenly need much more people to develop the application because of some explosive growth? Without documentation, new developers will just look at the application like they look at a painting. This actually happened to me. Maybe in the beginning of a project, a technology really helped you a lot but as the project grew, it started making things...

Some real soft skills which are useful as a developer

I keep hearing more and more that as a software developer you still need soft skills, that soft skills are more important than technical skills and so on. But no one really has any concrete ideas about what these soft skills actually mean as a developer. Everyone just keeps talking about them but I don't see anyone actually going into details about them with concrete examples. Not to mention that a lot of people are just trying to make money out of these things and when they say that soft skills are important it is usually followed by some self advertising about their soft skills trainings. And to make matters worse, some of these preachers, pardon people, don't have a lot of experience in the development field. Some of them are not that good developers and then they say, that not only technical skills matter but also soft skills. Maybe they are not so great developers because they also don't have good enough soft skills also. Now on to the concrete part of soft skills....

My thoughts as an experienced developer in this field.

To be honest, I would have never guessed that      I would end up saying these these things, especially jn the beginning of my career. As you become more experienced, you kind of get to see everything and you become less impressed by new things. Honestly there is some sort of repetitiveness in this field and we kind of like to reinvent the wheel quite often, because well, we become a bit too easily bored. Take for example how the web looks now, a lot of it has been borrowed from other places, mostly desktop development, especially the parts about making custom reusable components.  Or from older frameworks, like state management in the UI which actually was first properly implemented in Asp .Net Webforms, as far as I know, something like 20 years ago, where you used to have the dreaded view state.  But most likely something similar existed before that too. I was not that surprised when React adopted initially this idea. Or even less surprised when hooks where in...