TurboCharge your Mobile App Sales – The Video
The folks at Mobile Mondays Chicago were kind enough to post a video of the talk Todd Wyder and I gave to their group in February at Morningstar’s swanky offices on State Street.
A Simple Way to Use Aspirational Thinking to Elevate Your Product Design
Your desire is to make a great product. Or take an existing product to the next level. It’s great to have the intention, but how do you put that intention into motion?
Here is a simple exercise that you can try. Instead of thinking of the details of what might improve your product, simply consider your product as an “environment” or a place people go to get some kind of value. Try filling in the following sentences:
This is where people like to come to do ______________.
It’s way better than ______________ because of _______________.
Simply put, it’s the only place to go where you can ______________.
We can dissect these sentences and realize they are about thinking through differentiators, what makes the product competitive, etc. In narrative form, however, you are not just thinking of these items, you are also putting them in context of how they would sound to someone else. By using this “narrative” or mini elevator speech approach, you will likely find you are better able to come up with ideas that have an emotional tug.
Try emailing the sentences to your team and have everyone return a response. You can also use the exercise to kick off the beginning of a meeting or a brainstorming session.
Turnover…..JIT docs
You started a new job recently. Your organization has a some “legacy” apps, plus they’re working on a new batch using some cutting-edge technology. You’re assigned to a cool team with some hot-shot developers and ready do get down to work.
Suddenly, on day two, your manager walks by to let you know that the lead (and only developer) on one of the apps has resigned and will be leaving next week. Your manager asks you to pick up work on the project.
“Well gosh”, you think. “What a great opportunity to show my stuff”.
After a brief discussion with your soon-to-be-ex colleague, you realize this might not be a picnic afterall. The system seems to be functioning well and has a hefty backlog of pending work. However, when you inquire as to any form of documentation, you get a blank stare in return. Not only that, but the unit tests have been breaking of late, so most of them have been commented out. The build is manual and the deployment scripts work most of the time.
Well….now what?
Two suggestions come to mind:
1) Get in a room with your colleague and start a simple set of diagrams which depict the system top-down. These should be high level to begin with; a few architecture diagrams covering the technical and the conceptual aspects. Next ask about the complicated parts of the system and get some interaction diagram out on the white board. Next, make sure all the build and deployment information is documented and that they actually work (you can reproduce those steps yourself). Finally, ask about technical debt. Create chores to fix all the “we don’t have time to fix that now” gotchas. Lastly, take pictures of everything and write up the info in simple form. Posting on a wiki is helpful and if you’re using a tracking tool like Pivotal or ScrumWorks, enter everything in there.
2) Talk to your manager about introducing pair programming into the team to avoid this kind of situation in the future. Make sure you keep the unit tests passing 100% of the time going forward.
The moral of the story: while system documentation is important, it can be created just-in-time. A good practice is to use a wiki to keep all environment information logged and up to date. Trying to keep system document current is unnecessary as no one will read it until……at least he/she didn’t get hit by a bus.
Agile in FDA Regulated Medical Software – Checklists
Lets be honest: Checklists aren’t the most exciting topic to blog about. However, in the context of regulation they become interesting. Everybody loves checklists and hates them at the same time. It’s really easy to make them and just as easy to forget to use them. Later on, after the emergency and/or reason they were created has subsided, using the checklists becomes a ceremony – something that must be done rather than a helpful tool. Checklist also may foster an anti-change mentality and allow people to cruise through their jobs without think about them. This is why we all hate them.
Photo By: adesigna
All feelings about checklist aside: If each detail of your project’s history is going to be scrutinized, checklists are essential. On a regulated project their are a lot of steps to follow. It’s hard to remember each step of each procedure followed. Its really easy to finish delivering a feature then forget to check the software verification report in to your document management system. Once this occurs it looks like you didn’t test the feature before checking it in. Worse, you moved on to the next step of features and never turned in the verification report ever. 9 months later an auditor finds it and you have to doubly prove you did the testing and that you didn’t miss any other steps someplace else. Nobody wants to be in a position where they are on the defense. Often a missed step means all of the testing and tracking is nullified.
There are number of things you can do to ensure you have good lists and they get used often.
- Make them short – A 10 page checklist is not going to be used properly or use up time at the cost of efficiency. Train your staff. Don’t rely on process to get quality work.
- Have less steps – Can you tighten up your process and simplify it?
- Create checklist by role rather than at stage gates – The list will be shorter and highly focused on what matters to the person doing the work.
- Have the team members create their own checklists – They can identify the handful of tasks that are at risk of getting missed. That’s your checklist!
- Review checklists often for new procedures and question why each step exists often.
Finally, keep in mind that whatever you put on the checklist becomes part of your project documentaiton history. Thus, you must do every item on the list every time you run through a procedure. Think carefuly before adding things to a checklist.
Next up: Functional Testing vs Technical Testing
Use “Made to Stick” Principles to Improve Your Product Design
For anyone involved in product design, I highly recommend the book Made to Stick by Chip Heath and Dan Heath. The book does a great job of explaining 6 principles that characterize products that “stick” in the minds of customers. The principles are:
- Simple
- Unexpected
- Concrete
- Credible
- Emotional
- Stories
For product designers, these principles are great tools for improving your product design. Much of what makes a design successful comes back to the critical thinking that drives what the core product is. Is the core product simple? Does it have an emotional tug? Can you express the core product in a story that evokes imagination? You can use the Made to Stick principles to guide the critical thinking process and involve your team in that process. You can also use the principles to judge the likelihood your product or a competitive product will “stick” in the minds of customers.
Made to Stick is a practical and insightful book that can be read cover to cover or a section at a time. The book includes numerous examples to illustrate the six principles and quick exercises to help you hone your skill at applying them.
Just one……
How many time have we heard some form of the phrase “it just a one line change”? Or “it shouldn’t effect anything else”?
I think we know the all to frequent result…..”I can’t believe THAT broke……!!”.
Good developers write automated tests to help surface side-effects like this before they get into production and cause real damage.
Good developer refactor code mercilessly to make modifications less error prone.
Good developers take the perspective that maintenance begin as soon as you write “just one” line of code.
Getting a version 1 product out the door is hard work. Keeping the cost of ownership reasonable afterwards, so others can maintain your code, requires a perspective of continuous maintenance.
Agile in FDA Regulated Medical Software – Have Some Class
The FDA states that a medical device is a product that is used for medical purposes in patients, in diagnosis, therapy, or surgery. As opposed to a pharmaceuticals, who use the body’s metabolism, medical devices act mechanically or chemically. The FDA’s role in this is to assure the safety and effectiveness of devices. Keep this in mind while going through the process (they are not just to make your life hard).
Photo By: birlewphotography
From a software developer’s perspective, there are three classes of medical devices the FDA regulates. You should know what kind of product/device you are making very early on – before you start planning the work. Their are legends of companies that have outsourced development only to find that their partner had yet to take a device to the point where the FDA would audit it. An even worse scenario: they had done the work with an offshore partner who didn’t fully understand FDA requirements and couldn’t prove traceability nor pass an audit. Whatever cost effectiveness a company offers, make sure its not going to be at the expense of doing the project twice.
Class I
Class I devices are not intended to be used for supporting life. As such, they have the least regulatory controls. Product development efforts lend themselves well to utilizing Agile practices. Do some research before you start development though. About 74% of devices are exempt from pre-market notification in the first place. Those that aren’t, might fit into an existing device panel. Often a few pages of documentation will suffice to pass pre-market approval for Class I devices. To find out more go to the FDA’s classification database.
Class II
For Class II devices, the FDA recognizes that general commercial quality control and manufacturing practices alone may not be sufficient to assure safety. However, they state that “existing methods” are in place to prove safety. You will still have to prove this to the FDA. Simply put: If you follow a process, and document it, you will be able to prove the device you are creating is safe. Rely heavily on documenting the history of the project well. The project will be characterized by significant documentation and process compared to a “normal” Agile project. Because Agile is quite new in the FDA space, you will probably need a seasoned compliance officer with FDA experience. Plan to get audited. This doesn’t mean that utilizing Agile practices is difficult or shouldn’t be done. In fact, because so much time is spent on each feature of the software, I would argue that efficiency and managing waste become critical issues. Attacking risk and focus on delivering the highest value features first is key here. The team just can’t be sloppy with process or documentation for this type of device.
Class III
Class III devices are new or are used to sustain life. The team can’t rely on existing methods to prove to the FDA that the device is safe and labeled correctly. Time to market will play a part, but software development isn’t likely to be on the critical path of product development. The raw science and research are likely to take up most of the product lifecycle. Is agile right for R&D? That’s a topic better covered in another blog post.
Given the wide range the FDA has in place, the life of your product development team will be greatly affected by the classification of the device you are creating. In my experience, working on Class I and Class II devices often feel like working on a “normal” Agile project – assuming your Agile process incorporates enough controls to document the process itself.
Next Up: Keeping Track with Checklists
It’s All about the Team
Quick! Think back to your most fond projects. Were they the most challenging or the most profitable? Maybe, but I bet you had a great team. I’m convinced that the most rewarding and successful projects share a common attribute, an outstanding team.
What makes a good team?
Is it a collection of rock stars that work 90 hours a week? Nope. Instead it’s people that work well together with copious amounts of respect and willingness to help other team members even if they don’t have the same role (developer helping BA, BA helping tester, etc). Good team members are:
- honest. It’s hard working with people that can’t be trusted
- good listeners. They don’t need to put forth their opinion on every topic.
- on time. You don’t have to be on time, you can be early.
- mentors. They enjoy developing junior team members
- willing to fill in gaps. Isn’t it great when a developer speeds up the build or cleans up the CSS?
- not complainers. Complaining is really contagious and has a big effect on morale.
- skilled, but always improving their craft
- respectful
Pathfinder is always looking for talented developers who thrive in team environments. If this sounds like you, please check out our available positions.
Pathfinder Incubated ShuttleCloud at TechStars New York Demo Day
Tomorrow is TechStars Demo Day in New York, and I’m flying out to cheer on ShuttleCloud. We’ve been working with since last fall, and it’s been fun working with them through the TechStars experience. ShuttleCloud does cloud data migration, allowing companies and individuals to easily migrate their email, google apps and social apps between providers, something that is laborious and error prone without their service.
There’s a nice feature on TechStars New York in the New York Times today, and there should be a few more coming out over the next few days. I’ll be tweeting on it throughout the day, if my iPad can connect in a space with 500 wired investors.
Not Enough Time to Design? Try a Time-Boxed Workshop
Lean UX methods have become popular as a means of getting the core concept of a product and its business value on target with minimal time and expense. One of our favorite “Lean” design methods is the time-boxed workshop.
Why Time Boxing?
The best reason for time-boxing is it virtually guarantees forward progress and positive team work. By defining a clear topic and a time limit, people will literally think differently than if they are allowed to examine several goals without a time frame. They will be more focused, more creative and more collaborative. Better team chemistry results.
Time-boxing is also helpful when you really don’t know how long something is going to take. By time boxing and producing a single result, you’ll be in a better position to guage future efforts than if you over-invest in trying to estimate something but don’t start moving toward the goal.
How to Conduct a Time-Boxed Workshop
Below is a simple recipe for conducting a time-boxed workshop. Follow each step and you will see the benefits.
1. State the topic and make it specific. For example, “Workflow Definition” doesn’t cut it. That’s way too general. Instead, try something like “Define the top 5 workflows in the product and draw a picture of each on the whiteboard.”
2. Get the right people in the workshop. Make sure the relevant experts are in attendance.
3. Set up a parking lot and use it. Capturing ideas is important, but if they are off topic get them in the parking lot and move back to topic.
4. Let everyone know the ground rules. The goal isn’t perfection, it’s to achieve the objective as can best be done in the allotted time. Off topic ideas will be directed to the parking lot.
5. Watch the time. If you have two hours to define the top 5 workflows, pace the workshop accordingly.
Experience the Power of Time-Boxed Workshops
Whether you are designing a complex system or a game for a mobile device, try time-boxed workshops to increase team collaboration and get the most challenging part of your project moving forward. The more you do them, the more they will become an indispensable tool for getting things done.