App development today demands a three-in-one approach

Work with us

By Peter Hanschke

Welcome to the third installment of my blog on product managing myself. To recap, the first installment dealt with why I would even think of writing a mobile app. The second installment revealed the platform for my app and the importance of getting a name that is available and befits the app.

Today we’ll get into a meatier topic. Something that is fundamental to being a product manager – managing the intersection of product requirements, user experience and implementation AND remaining within a reasonable release window.

I cut my product management teeth on the waterfall process of software development. There are a number of forms (and names) for this process, but generally the high-level steps are: gather the user/customer requirements, design the solution, implement and test the code, and deploy the software.

The traditional gap between management, design

Product managers were primarily responsible for gathering the requirements from the users and also possibly the customer. Requirements were usually split in to functional and non-functional requirements. Functional requirements are a description of the functionality of the software and typically documented as use cases; this is a very action-oriented accounting for the various decision paths. Non-functional requirements are system, legal, languages, etc. – everything that was not part of the required functionality.

System designers were responsible for the design phase. This defined how the system would be implemented and any user interfaces. Development was responsible for implementing and testing the code and the release management person (or team) was responsible for deploying the software. From an organization perspective, product management could’ve been part of either the R&D or marketing teams, whereas designers, developers, testers, release managers were always part of the R&D team.

By the nature of the division of responsibilities and the division of the organization, product managers were never really part of the design process. As a product manager, my goal was to ensure that the requirements were complete and well articulated. As the project unfolded, I made sure that the functionality was implemented to meet the requirements. Getting involved in the design process was never part of my job, nor part of the process. I have to say that design in most cases was not high on the importance list. In many organizations the requirements were gathered, software was coded and tested and then shipped. Design ended up being part of the coding phase.

Bridging the gaps between functionality, experience, interface

Today the user experience (the steps that the user goes through to achieve their goal), and the user interface (the placement and characteristics of the interface elements) are front and centre … especially with mobile and web apps. Purchase and usage decisions, I believe, are made equally between functionality, experience and interface – any weak links can be disastrous.

As I work through my app I’m realizing the importance of getting all three right as well as the interaction between all three. I have also come to realize that a product manager in today’s world of developing applications needs to be proficient at all three. This is not to say that product managers need to be wizards at user experience and interface along with requirements management, but they do need to understand the relationships between them and the implications when decisions need to be made in each area.

No, you can’t do anything with code

As much as we like to say that anything can be developed in software, in reality the software developer is restricted by what the platform offers. In some cases certain things just can’t be built or it requires superhuman effort, time and cost. I spent a great deal of time laying out the UI and the flow the user will follow to execute the key use cases. After mapping this out, I would begin coding the elements and the flow. In some cases I spent many hours implementing more and more capabilities only to encounter a dead end, or a situation that became cumbersome for the user.

I could have implemented more code to work around the block, but (a) I did not want to have a bloated app, and (b) experience has taught me that workarounds will eventually come back to haunt you. I must have gone through four or five different designs! In most cases the platform did not allow me to implement the design and/or flow that I wanted … throw in Apple’s design guidelines and the result was that I couldn’t continue on the path I was on. Back to the drawing board (literally)! I finally settled on a design and flow that works well and can be implemented without any workarounds.

The takeaway here is that it’s OK to experiment and try various designs/flows in order to get it right. In fact I encourage it. I found this process a type of refinement where you eventually get down to the design that works for the user. The down-side is the discouragement you get when you realize that you have to start from scratch. There was one time when I really liked the design and after hours of implementation, I decided to start over. I thought seriously about quitting. But I wasn’t going to let this platform beat me, so I started over.

A word of caution, do not confuse this type of refinement with tweaking the code or the design to make it a bit better. The latter can go on forever; you will always find items that you can improve upon. At some point I do want to get this into the iTunes store.

I am getting closer and closer to the finish line. The next post will be on marketing the app. How can I stand out in iTunes? Is this even the right approach?

Image: Staff Infotech

Peter Hanschke is an Ottawa-based product management specialist.

Leave a comment:

Join us

Events We're Attending:

  • image description
  • image description
  • image description
  • image description
  • image description
  • image description
  • image description