Easy Data Transform and Hyper Plan Professional edition are both on sale for 25% off at Winterfest 2021. There is also some other great products from other small vendors on sale, including Tinderbox, Scrivener and Devonthink. Some of the software is Mac only, but Easy Data Transform and Hyper Plan are available for both Mac and Windows (one license covers both). Sale ends 11th January.
This is a guest post from fellow software developer, Simon Kravis.
Few developers would choose their development platform on the merits of their respective Integrated Development Environments (IDEs) but it happens that applications developed in Windows need to be made available on the Mac platform.
There are many environments offering cross-platform (Mac, Windows and sometimes Android) functionality, but close inspection shows that they all have limitations. Visual Studio (the native Windows IDE) can produce apps which will run on a Mac using .Net Core – but only if they are command line apps on Windows. Other environments (like Xamarin) do support interfaces, but only involving simple controls like text boxes or drop-downs. There are other cross-platform IDEs (such as Qt) which offer better graphics support, but they are not cheap and the extent of their support is not evident. If you need functionality such as computer vision, there seems to be no alternative to creating a separate code base for the Mac. Once you start on this path it becomes obvious that Macs handle graphics (and interfaces) very differently from Windows.
Macs have evolved rather more than PCs over the decades: they abandoned their proprietary Mac operating system in favour of UNIX in 1999, adopting the NeXTSTEP platform created by NeXT. Apple originally used PowerPC chips, replacing them with Intel Core processors in 2006, and they are currently transitioning to RISC chips. The Mac NeXTSTEP programming language was Objective C, developed in the 1980s and this is still supported, although the modern Swift language was introduced in 2014, and the Xcode IDE appeared in 2003. Xcode is free, even for teams. It uses the Cocoa API, which is accessible from other environments. The current release (MacOS 13.0) supports both Objective-C and Swift and is also used for developing iPhone and iPad apps. Mac operating systems since Catalina (released in 2019) are 64-bit only. Xcode can only develop apps for Apple operating systems, notably iOS, which powers the iPhone. Most of the web questions and examples relate to iOS rather than MacOS. MacOS uses different frameworks from iOS, so some functions used in iOS are not available in MacOS, or have different parameters.
The Windows IDE (Visual Studio) dates from 1997, when it bundled together Visual Basic, Visual Fox Pro and Visual Source Safe and Visual C++. It has an open architecture based on plug-ins and supports 36 different programming languages, but the major ones are C#, VB.Net and C++. Visual Studio can develop apps for any platform via the .NetCore framework, but capability for non-Windows platforms is limited. The Community edition is free, and has almost all the functionality of paid versions.
Both Visual Studio and Xcode are highly complex applications. They both have graphical interface builders where controls are dragged from a library onto a form. Each application has a vocal supporters and detractors. My experience comes from about 5 years with Visual Studio developing C# applications. Before this I worked with Visual Basic for Applications in Microsoft Access, so I am well-versed in the Microsoft way of doing things.
Like most complex applications, Visual Studio and Xcode each have plenty of bugs, often producing completely unhelpful error messages. Reporting an Xcode bug through standard channels resulted in … nothing. Not even an automated message saying “Thank you for feedback. It will be used to improve future versions”. I haven’t even tried to report a Visual Studio bug, but I suspect that the much larger user base for Visual Studio will mean that workarounds are more readily available, even if the giant ship of Microsoft takes years to respond.
Moving to the Mac and Xcode for development was a shock as I found I didn’t know how to do the most basic things. String manipulation (used in most applications) in Objective C is highly verbose compared to C#. Google was invaluable for finding answers – mostly they were from Stack Overflow, but often from 10 or more years ago, sometimes from Apple Developer Forums. As Xcode has changed considerably since then, answers often had to be adjusted before they could be used. Another problem is that functionality once provided externally has since been incorporated into Cocoa, so attempts to find a current version of a component (or framework as they called in Cocoa) are often unsuccessful.
MacOS provides more native functionality than Windows. Features such as computer vision and PDF generation are included in MacOS, rather than requiring the use of 3rd party components, which may not as robust as desired, and may require a license for commercial use. However, documentation of MacOS functionality, if present at all, was rarely useful. A few times I asked questions on Stack Overflow which attracted the ire of the Mac gurus for either through having obvious (to them) answers or through not conforming to the forum guidelines (in their opinion). However, the integration of NuGet with Visual Studio provides easy access to the massive number of 3rd party libraries available for .Net on Windows.
The model-view-controller paradigm used on the Mac took some getting used to, as did the design of the main Xcode screen. Sometimes a useful display would disappear and I had difficulty in finding it how to bring it back. I often had to resort to retrieving earlier versions from the excellent Time Machine backup. Form design is similar on both platforms – dragging and dropping components from a library. Both Xcode and Visual Studio have bugs, as would be expected for such complex apps. Events from components are generated automatically in Windows, but have to be defined on the Mac (as Actions). References to the component you’ve added also need to be defined on the Mac (as Outlets) and are not a property of the component, whereas on Windows they are.
The Xcode environment provides only basic facilities from scratch: if you need to do something more sophisticated you’ll have to Google around to find out how. Once you know – it’s easy, but the learning curve for Xcode is much higher than for Visual Studio.
Rather than starting from scratch with the Mac version of my Caption Pro app, which uses local computer vision functionality to detect multiple photos, changes image dimensions and adds text to images, I found an existing open-source project on GitHub with similar basic functionality. This dated from 7 years ago and used Objective-C, so that was the language I opted for. An immediate handicap was that many of the answers I found to my questions used Swift in their example code, which is not interconvertible with Objective-C in the way that C# and VB.Net are. iOS applications for the iPhone (which are most common) use different frameworks from Mac apps, and routines in them sometimes have completely different syntax.
The user interfaces for the Mac and Windows versions look quite different, as shown below. There are some basic differences – menus appear separately to the application window on the Mac and are locked to the top of the screen, whereas Windows menus are part of the application screen. Toolbars offer access to common functionality on the Mac. Differences also arise from the fact the Mac application was adapted from existing code rather than created from scratch.
Open-source examples (often from GitHub) are useful, but rarely work out-of-the- box. Sometimes the modifications need are minor – like defining the development team- but sometimes it’s not possible to get them to build in a current version of Xcode.
Debugging on Xcode is frustrating – the call stack frequently contains assembler (which is perhaps why app performance tends to be better on Macs), and the debug variables window does not list all relevant variable values. Variable types may not be correct – Boolean values may appear as dates, and sometimes variables cannot even be evaluated by po (print out) statements. Printing out structure variables may show nothing. Despite the generally superior performance of Mac apps, building apps in Xcode appears to be much slower than in Visual Studio on similar vintage machines, and after code stops at a breakpoint, it may take a long time before the variables window is filled. Deployment of Mac apps can still be done on an ad-hoc basis, but you have to register as an Apple Developer to avoid blockages in installation arising from being an ‘untrusted source’. Bypassing these blockages is more than a matter of clicking “Install anyway” so it’s hard to avoid forking out US$100 per year for registration. Windows has similar blockages, which can be bypassed with a code-signing certificate. These certificates are available from many vendors, and are slightly cheaper than Apple developer registration, but the process of obtaining one may be very involved.
Ad-hoc deployment is somewhat easier on the Mac than on Windows, but the method of doing it via Archive generation is anything but obvious. Mac applications are actually disk images and applications keep all of relevant files in a folder. This makes uninstallation a matter of dragging the application icon into the recycle bin, a far simpler process than on Windows. dmg files are not recognized by IIS web servers (and may not be by Apache either), so unless the file type is registered, download from a web site will not be possible.
Apple pioneered the App Store for iPhones (it is the only way in which iPhone apps can be installed) and Mac apps can also be put there. Apple takes a commission of 30% (or 15% if you are a small company) and they review all apps before adding them. Passing the review process may be a lngthy process, as not all problems are detected in a review cycle. Fixing these issues and resubmitting may result in further problems coming to light. The review process may also be somewhat arbitrary. One App Store app presented an interface in German by default. English was available as Preferences option, but only after guessing where the Preferences option was located. App Store apps operate within a sandbox, which places restrictions on filesystem operations. Whether App Store deployment makes economic sense depends on the nature of the app, its market and price structure. Its advantages are that it targets the 16% of desktop users who use Macs, and streamlines installation (and payment, if applicable). The App Store supports ‘freemium’ pricing, where additional features are made available to paying users, but apps with free trial periods are shown as being free but with ‘in-app purchases’, which annoys some users.
Windows deployment can use .msi files, which have been around for decades, but are not easily installed by non-admin users. Self-extracting executables are more tractable, but 3rd party tools have to be used to create them. Windows 10 introduced Universal Windows Programs, which are easier to install and can be placed in the Microsoft Store, which operates in a similar way to the Apple App store, but for Windows desktops and tablets.
A key question which is very difficult to answer is “How long will it take me to convert my Windows app to run on a Mac?” Factors affecting this are app complexity, functionality and programmer skill. The time between starting work on the Mac app and first deploying it on the company web site was about 3 months, but the amount of time spent on the project each day varied between zero and 3 or 4 hours. If you are a paid resource, then the cost of a cross-platform IDE may be justified, but the requirement for local computer vision functionality added a great deal of complexity to my requirements, which is one reason why I opted for a separate code base. Substantial evaluation would be required before deciding if a cross-platform environment could support any required functionality.
Simon Kravis runs Aleka Consulting, a small software and consultancy company in Canberra, Australia specializing in information management and offering a number of software products. He has mainly developed scientific and engineering programs, starting in the era of paper tape.
I started selling software online 16 years ago. Until this year I never had a forum for any of my products. I handled customer support for PerfectTablePlan and Hyper Plan by email and kept customers up-to-date with an opt-in email newsletter. But I rethought this position with my latest product, Easy Data Transform and started a forum at forum.easydatatransform.com in December 2020.
My ISP offered various forum software packages, but I really wanted Discourse, as I consider it head and shoulders above all the other forum software I have interacted with as a user (even if I find the badge system a bit patronising). I didn’t want the hassle of setting up and patching a Discourse server, so created the forum through www.communiteq.com (previously discoursehosting.com). It was suprisingly easy to set-up. And it gives the option to export everything, in case I want to part ways with them. The sheer number of options in Discourse are quite daunting, but I stuck with the defaults for the most part.
Some people use Facebook Groups for their product forums. Ugh. You have almost no control of such a forum. Facebook could even be showing ads for your competitors on your forums. Or they could just decide to shut you down and delete all the content. That is before we get on to the fact that Facebook make their money monetising hatred and abusing our privacy at an industrial scale. No thanks.
The advantages of a forum are:
- Letting customers talk to each other, and post content helps to create a community around the product. Which, in turn, can add a lot of value to your product.
- Customers can help each other with support questions. Sometimes they will answer before you are able to or will give a different perspective. Or even give a better answer.
- If a customer asks a question that has already been asked, you can send them a link to the appropriate forum page.
- It is a quick and easy channel to communicate with customers. I can post a link to a new snapshot release in a few minutes. This is much quicker than sending out an email newsletter. It is also more interactive as customers can respond on the forum and see each other’s responses.
- A lively forum is ‘social proof’ that your product is worth buying.
- A forum with lots of content should have a large SEO footprint.
The disadvantages of a forum are:
- The time to maintain it. A forum that is broken or full of spam and unanswered questions is worse than no forum.
- Disgruntled customers potentially airing their grievances in public.
- The cost of the forum.
- An empty forum looks bad.
- Bad actors can be a pain. For example, people posting links to spam or competing products.
It probably only takes me 1-2 hours per week to post on the forum at present. Some of that is time I would have spent answering support emails. If that rises substantially then I may have to delegate it.
I try very hard to provide a good product, with good support and haven’t had any issues with negativity, so far. But I know from my experiences moderating Joel Spolsky’s Business of Software forum that moderating a busy forum can be tricky, time-consuming and emotionally draining.
The cost of the forum is currently around $20 per month, so pretty low. That may climb, but hopefully sales will be climbing as well.
I was a bit worried about whether the forum was going to look empty. I warned customers that the forum was an experiment and would be closed if there wasn’t enough activity, to manage their expectations. I also created a ‘sock puppet’ account and ‘seeded’ the forum with a few support questions that I had been previously asked by email (with the permission of those that asked) and then posted answers. But I only did this a handful of times and then the forum started to take off.
I have heard stories of people getting 1000+ spam posts a day on their forum. But I haven’t had any issues with bad actors, so far. I’m not sure how much of that is down to Discourse and how much of it is down to luck. But, no doubt issues will occur at some point.
I still have my product newsletter, which I send out every few weeks when there is a new production release.
Overall I am pretty happy with how the forum is going. Should you have a forum for your product? As always, it depends. I think you should consider it if:
- Your customer base isn’t tiny.
- You want to interact with your customers and get feedback. This might be less the case with mature products.
- You have the time and energy to police and maintain it.
- Your product is relatively open ended or complex. For example, if your product just checks whether website are up or down, there is probably a very limited amount you can discuss.
The colours used in Easy Data Transform make no difference to the output. But the colours are an important part of a user interface, especially when you using a tool for significant amounts of time. First impressions of the user interface are also important from a commercial point of view.
But colour is a very personal thing. Some people are colour-blind. Some people prefer light palettes and others dark palettes. Some people like lots of contrast and other don’t. So I am going to allow the user to fully customize the Center pane colours in Easy Data Transform.
I also want to include some standard colour schemes, to get people started. Looking around at other software it seems that the ‘modern’ trend is for pastel colours, invisible borders and subtle shadows. This looks lovely, but it is a bit low contrast for my tired old eyes. So I have tried to create a range of designs in that hope that everyone will like at least one. Below are the standard schemes I have come up with so far. They all stick with the convention pink=input, blue=transform, green=output.
Which is your favourite (click the images to enlarge).
Is there a tool that you use day to day that has particular nice colour scheme?
I hope to also add an optional dark theme for the rest of the UI in due course (Qt allowing).
I released v1.1.0 of Easy Data Transform this week. It is a big upgrade, with some major new features.
There is a new Lookup transform. This allows you to lookup values for one dataset in another dataset. For example, if you have a dataset with a column for country code and another dataset with columns for the country code and tax rate, you can look up the tax rate by country code.
Previously you could only output your data in Excel and delimited text formats (including CSV and TSV). The new release also adds output to JSON, HTML, Markdown, vCard, YAML and XML formats.
I have improved the speed of the Join transform significantly using hashing. This makes a big difference with large datasets.
To save time, Easy Data Transform guesses the likely columns you want to use as keys when you Join, Intersect, Lookup or Subtract two datasets. For example if 2 datasets both have colummns called ‘ID’ with lots of unique values that are common to both columns, it will choose those two columns as the default key columns. I have improved the heuristic used to set the default columns.
You can now add comments to input, transform and output nodes as a note to a colleague or your future self.
You can now snap your input, transform and output nodes to a grid, so you can keep your layout all lovely and neat.
I have also made some bug fixes and minor improvements.
Haven’t tried Easy Data Transform yet? Got some table or list data that you need to wrangle into a more useful form? Take the free trial for a spin.
I finally released a paid version of Easy Data Transform today, for both Windows and Mac. I am very pleased with how it has turned out. Obviously it is only v1.0.0, so there is plenty of additional features I could add, including:
- Batch processing
- Support for JSON, XML, SQLite input/output
- More transforms
- A 64 bit version for Windows
- A Linux version
But I need to listen carefully to prospective customers to decide which additional features to prioritize in future releases. It might be something I haven’t even thought of.
But v1.0.0 already has a really useful core of features. And, if you aren’t embarrassed by v1.0, you didn’t release it early enough. That said, I haven’t cut corners on quality. It has proper documentation and has been through extended beta testing, dogfooding and several rounds of usability and third party testing.
The product has a fully-functional 7 (non-consecutive) day free trial. I think that is enough for prospective customers to decide if it does what they need. I also have a 60 day money-back guarantee.
I have decided to go with a subscription model: $99 / €90 / £75 + tax per person per year. Which covers up to 3 computers. At this price point I can afford some paid promotion and to provide a decent level of support. I am not offering a monthly subscription, as I don’t really want people who are going to pay for 1 month (to do their annual TPS reports) and then cancel.
I am continuing to work on my new product, Easy Data Transform. I have thrown together a 3 minute video to give an idea of what it is capable of.
You can download Easy Data Transform for Windows or Mac here. The beta is completely free, but time-limited (I do plan to start charging at some point). Please try it and let me know what you think.
I don’t really enjoy doing screencasts or voiceovers. If you can recommend someone who does slick screencasts and voiceovers (or who can polish my amateur attempts), please feel free to give them a plug in the comments.
I have been furiously coding a new product. Easy Data Transform. It is a Windows and Mac tool for transforming table and list data from one form to another. Joining, splitting, reformatting, filtering, sorting etc.
I have been thinking about this product idea for years. In fact I threw together a janky prototype back in 2008. It allows you to perform various operations on a pair of lists.
I used this prototype for jobs such as creating a list of emails of people who had bought Perfect Table Plan v5, but hadn’t upgraded to v6 yet. It worked. But it wasn’t very good. The biggest annoyance was that each operation obliterated everything that came before. Which made it very easy to lose track of where you had got to. And there was no repeatability. It was also limited to lists and it became clear that I really needed something that could also handle tabular data. I never released it.
But the idea has been running as a background process in my brain for 11 years since. And I think I have come up with a much better design in that time. Finally I had mature, stable versions of my Perfect Table Plan and Hyper Plan products out, so I decided to go for it. I am really pleased with how it has turned out so far.
If you aren’t embarrassed by v1.0 you didn’t release it early enough. And so I have cut lots of corners to get this first public version out. The documentation is only part written. I created the application icon myself in 10 minutes. There is no licensing. The GUI is lacking polish. The website would make a designer cry. But the software seems fairly robust. My 13 year old son wasn’t able to crash it after 10 minutes of trying, despite financial incentives to do so.
I did some market research and spoke to some people who knew a bit about this market. But I deliberately didn’t look closely at any competing products, as I didn’t want to be mentally restricted by what others have done. For better or worse, I want to blaze my own trail. Copying other people’s stuff is a zero-sum game with no net benefit to society.
Most of the things that Easy Data Transform you can do, you can also do in Excel or SQL. My claim is that it is much quicker, easier and less error prone to do in Easy Data Transform. No programming or scripting required. I am hoping that people will be able to start using it within a couple of minutes of downloading it (I plan to do lots of usability testing). Will people pay for that? I hope so. I’m not aiming it at programmers. Perish the thought.
Naming is hard. I came up with some 70 names. Things like ‘Data Hero’, ‘Transform Flow’, ‘Transmogrify’ and ‘Data Rapture’. But the domains were taken, people I asked hated them or there was an existing service or product with that name. So I ended up with Easy Data Transform. It does what it says on the tin.
Why desktop? Surely no-one is writing new desktop apps in 2019? I believe a desktop solution has some real advantages in this market. The biggest ones are:
- You don’t need to load your (potentially highly sensitive) data on to a third party server.
- Not having to upload and download (potentially very large) data sets makes it much more responsive.
Easy Data Transform is currently free for anyone to use. You can get it from the super-minimalist easydatatransform.com website. The current 0.9.0 version expires on the 4th August 2019. You will then be able to get another free version. Once the product is mature enough, and if I am convinced there is enough demand, I will release a paid version. The free beta will probably last several months. Please try it and let me know how you get on. I am particularly interested to get feedback from anyone using it for real day-to-day tasks.
Of course the real challenge is always marketing. How to get noticed amongst many competing products. As well as helping to improve the product I am hoping that this extended beta will also help me to get some traction and better understand the market. For example, what price to charge and what trial model to use. Watch this space.
This is a guest post from roving software entrepreneur, Steve McLeod.
Each feature you add to your software product takes time to implement, adds ongoing complexity, and is hard to get rid of later. So you need to choose wisely when adding new features.
Here are some tips on choosing which features to implement.
Does your product really need new features?
This question might be surprising, but it is an important one to ask yourself. A software product is never completely finished. There is always scope for improvement. This makes it hard to know when to stop working on it.
If your product is mature and has stable revenue, there might not be much opportunity to increase sales. Adding new features would please some customers, but would not be a good use of your time.
Products that should be considered “done” can still have a large backlog. Don’t be fooled into thinking that your product will only be done once all existing feature requests are done.
Your product might have great potential to grow, but not by adding new features. Perhaps you need to improve your sales and marketing efforts. Don’t use your feature request backlog as an excuse to neglect the other important parts of running your product.
It’s okay to ignore your backlog
Feature request backlogs seem to never shrink. Implementing improvements leads to even more feature requests.
Looking at your backlog can be overwhelming. You’ll see feature requests that are years old. There are others that you intended to implement, but never did. It is okay to ignore these.
Don’t feel that the entire backlog consists of promises that must be kept. Some requests are no longer relevant. Some are from customers who no longer need your product. Some are simply not worth the substantial effort.
Keep your grand vision in mind
Prefer to implement highly requested features. But before you do, make sure each feature fits your long-term plans. Ask yourself:
- who is your ideal customer? Is the feature relevant to them? For example, your enterprise customers might be asking for “single sign-on”, whereas you are more interested in working with small businesses.
- will this be an ongoing cost- and time-sink? For example, a particular feature could require HIPAA (a US health industry regulation) compliance, while you have no interest in the extra workload and costs of HIPAA compliance.
- does this proposed feature agree with your marketing angle?
Each new feature has ongoing costs
Remember that each additional feature comes with ongoing costs in support and complexity. Each new feature is an additional place for bugs to hide, adding to your future workload. Take these future costs into account when deciding if a feature should be added.
Features interact with each other, sometimes in unexpected ways. Even one additional checkbox in a settings panel can lead to ongoing confusion.
Be wary in particular of features that require integration with third party products. For example, many a product owner was burned when Twitter turned off some parts of their public API. Another example is my own experience adding support for connecting to customers’ email inboxes. I then found myself supporting not just my own product’s problems, but those caused by customers’ email service provider.
Sales-blockers are high priority
Not all feature requests are equal. Requests for feature A might come only from long time customers of your product, while feature B is requested only by your trial customers. It sounds ruthless, but you should prioritise the feature requested by trial customers.
When running a business, you do need to care for financial concerns. Take into consideration that:
- A trial customer is likely to report a showstopper (for them). When you implement features requested by several trial customers, you are likely to increase revenue.
- An existing customer is likely to report an inconvenience. You probably won’t lose the customer by delaying the improvement they asked for.
- You need new customers to keep your business healthy.
It is important, of course, to care for existing customers. Don’t take this as an argument to ignore existing customers altogether in favour of potential customers.
Identifying and fixing sales blockers as a matter of priority is especially important for new products. It takes time to find the right balance of features a new product needs to meet the demands of the market.
Prefer the easy things, but not always
Let’s say you are deciding which of two features to implement next. Both feature A and feature B have been requested dozens of times. Feature A will take a week’s worth of work, and feature B will take a month’s work. Which one do you do?
Feature A, right? Maybe not.
Feature A is usually the correct choice. But you’ll be repeating this scenario over and over. Your product will gradually gain many relatively trivial features, while never getting the important features you need to create a compelling product.
Sometimes you need to do the hard work to add the features that are difficult to implement.
Listen to your customers…
Your customers are a great source of ideas for improvements to your product. As they use your product they discover what’s missing and what’s poorly implemented.
Therefore make it exceedingly easy for your customers to get suggestions to you. Consider adding a “Suggest an Improvement” link to your support page and to your help menu, if applicable. This makes it clear to your customers that you are actively seeking suggestions. My experience has been that customers notice these links and use them.
A “Suggest an Improvement” link can be as simple as a “mailto” link. A basic dialog or web form also works well. If you are seeking inspiration on how to do this, look at the “Report an Issue” form linked from the Google Chrome’s Help menu.
Another way to get customer suggestions is by asking them via a survey. This is okay, but it requires people to imagine back to when they last used your product. Us humans tend to be pretty poor at recalling things. It is much better to encourage customers to send suggestions as they encounter difficulties, while it is foremost in their mind.
I found collecting and organizing feedback for my own product, Poker Copilot, to be a pain. So I launched a new product to help manage feature requests. It allows your customers to suggest and upvote improvements for your product.
…and not your competitors
You’ve probably already heard that you should “listen to your customers, not your competitors.” I’m repeating it, because forgetting this can be deadly to your business.
Feature-envy leads us to believe we have to add every feature our competitors offer. Like regular envy, it is best to ignore it.
When your competitor announces a new feature, it can be demoralising. You feel you are falling behind and unable to compete. If the feature looks impressive, you’ll be tempted to add it to your product as soon as you can.
But wait. Have any of your customers actually requested this feature that your competitor added? If not, it is probably because it is not all that useful to your customers.
Your competitor might eventually regret adding that feature, as it turns out that only a small but demanding percentage of their customers use it. By not adding it, you could be giving yourself an advantage.
I’ve discovered that customers often learn about the good features my competitors have. They then tell me that they want these features. Only then do I start considering adding them.
Small tweaks versus major features
I just recommended listening to customers. But be careful of only using customer requests as a source for improvements.
Your customers tend to ask for incremental improvements. Customers are more likely to ask for an additional option in a drop-down menu than they are for a innovative new way to view their data.
If you rely on customer suggestions alone, you’ll never get the innovative new features that can make your product something much grander.
Make sure you balance your customer-contributed requests with your own innovative improvements.
Beware of preferring “pet” features
I just argued in favour of choosing innovative improvements. However this comes with a warning. Innovation can be used to justify poor choices. When you are in charge of decisions for your product, you are in danger of choosing improvements that you find interesting instead of those that have a strong business case.
Be careful. You could spend months working on a feature that is not very helpful to your business.
This is the type of feature that only one customer requested, but because it sounds more interesting to you than anything else in your massive backlog of feature requests, you immediately start working on it.
My own experience with this: I added scripting to a product even though no-one had asked for it and my target customer was not the type of person who would be interested in custom scripting. When I announced the scripting feature, not a single person seemed to use it. I eventually got rid of it.
How do you decide?
The tips I’ve offered you in this article come from my own experience. Do you have tips of your own for deciding which features to implement? If so, please add them in the comments below. I’d love to read them!
Steve McLeod runs a small software company in Barcelona, Spain. His products are Poker Copilot, a desktop analytics app for online poker players, and Feature Upvote, a web app that allows your customers to openly suggest and upvote features they want to see in your product.
I have heard various product owners beating themselves up about how they don’t have enough of a social media presence. Well, I have been running a profitable one-man software company for the last 12 years and I am here to tell you that neither of my products have a social strategy worthy of the name – and that’s OK.
My seating planner software, PerfectTablePlan, has a Facebook page and a Google+ page. Whenever I publish a newsletter for PerfectTablePlan I publish a link to the newsletter on these sites (which is a few times per year). That’s pretty much it. My visual planning software, Hyper Plan, has an even smaller social media presence than PerfectTablePlan. To be honest the small amount I do on social media is intended mostly for the benefit of the mighty Google.
My forays into social media have not been encouraging:
- I once sent out a newsletter to over 3000 opted-in subscribers and encouraged them to follow a newly created PerfectTablePlan Twitter page. Exactly 0 of them did.
- I created a Pinterest page for PerfectTablePlan and paid someone to post to it for a few weeks. It generated a bit of traffic of questionable quality, but the traffic dried up as soon as they stopped posting.
- I have tried paid ads on Facebook and Twitter and the results were miserable.
- The PerfectTablePlan Google+ page has just 14 followers.
- The PerfectTablePlan Facebook page got a miserable 4 views last week.
The question isn’t whether social media can bring you traffic, but whether that traffic will convert to sales and is social media the best use of your limited time? Social media is a productivity black hole and the opportunity costs of noodling around on Twitter should not be underestimated. Also various studies show that email still out-performs social media by quite a margin.
“E-mail remains a significantly more effective way to acquire customers than social media—nearly 40 times that of Facebook and Twitter combined.” McKinsey
People go on social media to chat to their friends and look at cat videos. Not to buy things. They use search, Amazon and Ebay for that. When is the last time you even looked at an ad in the Facebook sidebar? Or clicked on a sponsored post in Twitter? Exactly.
Making an impact on social media is hard. 90% of tweets are not retweeted. And even the followers that are real humans may only be interested in discounts:
“The IBM Institute for Business Value found that 60-65% of business leaders who believe that consumers follow their brands on social media sites because they want to be a part of a community. Only 25-30% of consumers agree. The top reason consumers follow a brand? To get discounts – not exactly ideal for a company’s bottom line.” Forbes
A lot of the ‘engagement’ on social media is fake. You can buy 1000 Twitter followers for less than £10. The BBC advertised a fake business with “no products and no interesting content” as an experiment on Facebook and got 1,600 highly suspicious ‘likes’ within 24 hours. Copyblogger deleted their facebook page due to the amount of fake followers and the low level of engagement.
A thread I started on the Business of Software forum showed that many other small software product companies had tried and failed with social media. Why do you think you will fare better? Most software products just aren’t inherently social. There is a limit to how much you can usefully say, day after day, about seating planning. I could try and create a social media presence talking about the latest wedding and catering trends and try to sneak in some references to seating plans. But I would rather commit suicide with a cheese grater.
As a rule of thumb it might be worth putting serious effort into social media if yours is the sort of product people are likely to talk to their friends about down the pub. In that case social media may be able to usefully enhance your visibility and reach. But for the vast majority of software that doesn’t fit this description, you are trying to hammer a square peg into a round hole. At the time of writing the pop star Taylor Swift has 74,638,154 Facebook likes. While Intuit, one of the world’s largest software companies, has 221,130 likes.
Next time somebody tells you that you must have a social media campaign ask yourself:
- Is your product a good fit for social media?
- Do they have an agenda, e.g. a social media tool, ebook or consultancy to push? Or an article quota to fill?
- Have they produced any real evidence that a social media campaign translated into actual sales?
- Is social media the best thing you could be doing with your valuable time?
Ignore any vague waffling about ‘engagement’. Nobody ever paid their mortgage with engagement.